5.21.05.21.0

How the job works

The job works by identifying persons in Pure that have a Scopus Author ID (this includes active and former persons). The job will then query Scopus with that ID and check if:

1. Scopus has a record of that Author ID (regardless of whether the person is active or former)
2. The ID is current (or has been taken over by another ID)
3. The spelling (including variants) of the name in Pure matches that of the author profile in Scopus
4. There is an overlap between the publications related to the author in Scopus, and the publications related to the person in Pure.
5.  Has an ORCID (regardless of whether the person is active or former)
   1. If "Enable ORCID check" configuration is enabled
6.  Is an Active Academic
   1. If "Enable name check" configuration is enabled

Based on the above steps, the job will determine if the Scopus Author ID found in Pure should be kept, or suggest it be removed. The job can be configured to also use name(s) and ORCID. In the case where only an ORCID is found on the person in Pure, the job will attempt to find the relevant Scopus Author ID and add it as a suggestion on the person.

If the job finds that a Scopus Author ID on a person is a perfect match, i.e. the name and root organisation match and there is an overlap of research outputs, it will convert the Scopus Author ID to a verified ID, signified with a distinct badge on the ID.

The job will verify and suggest removing IDs on all persons (active and former), but will only add IDs to active persons.

To configure the job

The job can be found at Administrator > Job > Cron job scheduling > Match Scopus IDs for Persons. The job can be scheduled to run at pre-selected times. For Pure Portal customers, we highly recommend running this job during off-peak hours as any changes to Person data will trigger portal updates.

Default configurations The Default configurations section of the job provides context for how the job should run in terms of adding or removing Scopus author IDs. Root organisation(s): A root organisation(s) will need to be set – the root organisation(s) will be used extensively in the matching process. The root organisation requires a Scopus affiliation. Use the quick-add button to add the top level organisation of your institution. Excluded persons: This is to be used if, for example, a person has two Scopus author IDs, with one linked to a previous name and the other linked to their current name. The job will suggest removing IDs if a name in Pure does not match what is found in Scopus. Limit to persons: This option can be used, for example, to isolate problematic person profiles, or to help with debugging. Enable debug: The job can provide a detailed log of all steps taken and resulting actions for each person. As this is a resource-intensive approach, we suggest using debug mode with a set Limit to persons. Enable dry-run: The job can show results without applying the changes. Remove all Scopus Author IDs added by the job: If required, all IDs added by the job can be readily identified and removed.
Scopus ID removal actions Coupled with the default configurations, options provided here will determine what should be done to Scopus Author IDs if found to be taken over by another author ID, not found in Scopus, or if the ID is found, but the name and organisation do not match and there are no overlapping research outputs i.e. the ID is incorrect. For each scenario, select what removal action the job should take: Always remove Mark as candidate for removal Do nothing If Always remove is selected, the ID will be immediately removed whereas if Mark as candidate for removal is selected, a distinct badge will be shown next to the relevant ID on the person editor. If Do nothing is selected, the ID will remain on the person and will not have a badge attached to it.	Example of badge on Scopus ID when 'Mark as candidate for removal' is selected:
Scopus ID addition actions Options provided here allow the job to use the ORCID for searching and verifying in Scopus, and for a name search (within the root organisation - as defined in the general configuration). Based on the above input data, if the job finds a Scopus Author ID that matches the author name, organisation, and has overlapping research outputs but is not already present on the person, it will add the ID to the person with a distinct badge.

Editing Scopus Author IDs in the person editor

Users can edit the ID and can change the badge if necessary.

Synced IDs

Synced IDs will also be scanned but will never be removed or marked as verified. If the ID appears to be incorrect, no removal action will be taken but the ID will receive the Candidate for removing badge. The badge serves as a notification that the ID needs to be checked and, if necessary, updated in the sync source data.

Inspecting the job log

Whilst we will always recommend only enabling debug when limiting to specific persons, the debug log entries provide valuable information on problematic person data. After each run we suggest reviewing the job statistics. The summary includes the counts of IDs added, suggested for removal, verified etc. It also helpfully provides phrases to search the job log for inspecting specific persons under specific parameters.

Problematic Scopus IDs

We suggest reviewing the warnings in the job log and searching for the phrase ‘WARN: Could not check Author ID in Scopus - please perform this check manually’. This is a general warning and requires close inspection of the person and any Scopus IDs associated with that person.

Examples of problems the job encounters to trigger this warning:

• Person has added a non-standard ID as a Scopus ID. Common examples include a URL instead of an ID.
• For a standard ID, Scopus returns multiple taken over IDs.

Enabling preprint sub-type

Selecting Preprint sub-type as a user

When enabled, Preprints are displayed as a sub-type of the working paper template. To manually create a preprint, users should select 'Research output' - 'Working paper/Preprint'template and then select the 'Preprint' sub-type.

Importing preprints

Specific import sources have been mapped to the preprint sub-type. When a user imports content from:

• ArXiv
• MedRxiv
• BioRxiv or
• SSRN

The import will appear by default as a preprint. Users will still be able to change templates if necessary.

When importing from other research output sources not listed above, if no journal data is found on the record, the imported content will also be mapped to the preprint sub-type.

The preprint editor

The fields available on the preprint editor are as comprehensive as possible to cater for different institutions needs and interpretations of what a preprint can be.

We highly recommend adding your users' most frequently used preprint servers as Publishers to help them maintain the best possible record.

Migrating content to the Preprint sub-type

If your Pure already has preprints (but defined under different research output templates/sub-types), you can bulk change these to use the preprints sub-type. However, please note that some fields (such as Journal data in a Journal Article) may not be mapped to the preprint sub-type. Any fields not mapped will be added in the history and comments tab of the specific content.

Preprints in Reporting and Web Service

As the new preprints sub-type is part of the working paper template, it is automatically available in reporting and the WS.

Between which content types can you propagate keywords?

There are predefined directional flows between content types. Keywords can only be propagated from specific content types to other specific content types. These are shown in the table below:

What's the difference between Suggested keywords and Automatically accepted keywords?

Suggested keywords need to be accepted by users themselves before they are available on content, while Automatically accepted keywords are immediately displayed on content. The ability to have automatically accepted keywords gives administrators more control over which keywords should be immediately displayed on content

Suggested keywords

These are displayed on the target content type within their own section called 'Suggested keywords'.

In the example below, we have previously configured the SDG job to propagate SDG keywords from research output to projects as suggested keywords. When a user manually adds an SDG keyword to a research output (source content type), or the SDG job automatically adds it to the research output, the same keyword is presented as a suggested keyword on any related projects (target content type). A user will need to manually accept (or reject) the keyword on the project.

Source content type keyword display:

Target content type keyword display: If a user then accepts (clicks the +) the keyword: If a user rejects (clicks the - ) the keyword:

Automatically accepted keywords

These are displayed directly on the target content type as an accepted keyword.

In the next example below, we have previously configured the SDG job to propagate SDG keywords from research output to projects as auto-accepted keywords. As before, when a user manually adds an SDG keyword to a research output (source content type), or the SDG job automatically adds it to the research output, the same keyword is automatically added as an accepted keyword on any related projects (target content type). If a user then removes it, it is added to the rejected list on the target content type.

Propagate keywords between content types: all keyword groups except SDG Keywords

Keywords can be propagated between content types when the same keyword group is present on each content type. Note: there are specific flows between content types, and not all content types can propagate to all other content types. 

Propagate keywords between content types: SDG keywords

SDG keywords that are automatically added to research output and persons (via the Management Of Keywords Reflecting Sustainable Development Goals (SDGs) Job - the functionality and use of which is covered extensively in the 5.20.0 release notes) can now be propagated as suggested or automatically accepted keywords.

If, for example, the SDG job does not add any keywords to persons or organisations due to them having sparse or no descriptions, administrators can now propagate SDG keywords on research output to the contributing person and organisations directly. You can also propagate keywords from research output to projects.

To configure the propagation method, Administrators will need to configure the SDG job and not the keyword group.

User can add multiple Scopus Affiliation IDs to be used as the only search input or in combination with other search terms.

Enabling the integration requires a valid Scopus subscription, which needs to be configured in the Scopus import configuration. The integration will issue a warning if the Scopus subscription is not configured. 

The integration will be paused if Pure detects a change in the environment. This is to ensure that multiple client systems are not querying the Scopus API, potentially causing throttling issues. This can be circumvented by confirming the configuration of the system in the top dialogue box (note this might also effect other jobs) or explicitly allowing the integration to run using the toggle in the job configuration. It is recommended to not run the integration in test/staging systems unless you are testing that specific integration.  

To enable the integration simply use the enable toggle and press save. By default, the job will not run within standard office hours (9AM to 5PM). This can be further configured or disabled in the configuration tab.

If the integration has been successfully enabled, its status can be tracked in the Import status and log tab. Here, you can see how much content it intends to update, when the next job will run, and view the last 25 job log entries. 

Enabling the integration does not require a valid SciVal subscription. If no valid credentials are entered, only FWCI codes will be imported. This works out of the box for all hosted clients, but for self hosted clients you need to contact Elsevier and provide your Pure IP address. We will then forward these to the Scival team for whitelisting.

Valid credentials are needed in order to import the full range of metrics from Scival. These do not require IP whitelisting and can be entered in Administrator > Scival Access as shown below:

The integration will be paused if Pure detects a change in the environment. This is to ensure that multiple client systems are not querying the SciVal API, potentially causing throttling issues. This can be circumvented by confirming the configuration of the system in the top dialogue box (note this might also effect other jobs) or explicitly allowing the integration to run using the toggle in the job configuration. It is recommended to not run the integration in test/staging systems unless you are testing that specific integration.  

To enable the integration simply use the enable toggle and press save. By default, the job will not run within standard office hours (9AM to 5PM). This can be further configured or disabled in the configuration tab. 

If the integration has been successfully enabled, its status can be tracked in the Import status and log tab. Here, you can see how much content it intends to update, when the next job will run, and view the last 25 job log entries. 

To pause the integration:

1. Toggle Enable Scopus metrics import to Off.
2.  Save the settings.

When paused, the integration will no longer update metrics, but you will retain the already imported metrics.

To remove all imported metrics:

1. Pause the integration.
2. Select the Remove metrics button.         
   Note: This button will only be visible after you have paused the job.

You can see the status of the removal job in the Import status and log tab.

Instructions on how to enable, add, and search for content from researchmap are shown below.

To configure the export to DSpace go to Administrator > Storage , select DSpace and Configure new store.

At the bottom of the configuration settings, in Conditions for storage, you can select Datasets as a content type from the dropdown.

Thesauri with updates:

• OmniScienceChemistry (Chemistry)
• Compendex (Engineering & Materials Science)
• Geobase (Earth & Environmental Sciences)
• MeSH (Medicine & Life Sciences)
• NAL (Agriculture & Biology)

Thesauri without updates (with regards to previous version 8.0):

• Humanities (Arts & Humanities)
• Economics (Vocabulary)
• Gesis (Social Sciences)
• Math (Mathematics)
• NASA (Physics & Astronomy)

Please note: The update to the new Fingerprint Engine version will not happen automatically upon the update to 5.21.0. Instead, the update will be scheduled at a random point in time, sometime within one week of your Pure being updated to 5.21.0. This applies for both Pure-hosted and self-hosted clients. It is done this way to spread the load the update causes on our servers.

We expect the update to take a maximum of 24 hours. During this period, the 'Copy/paste text - find expertise' search tool will be unavailable.

You can check when your update is scheduled by going to Administrator > Fingerprint > Configuration.

To disable the display of the Scopus Profile links across your Portal:

1. Go to Administrator > System Settings > Scopus.
2. Toggle the option Scopus link on portal to Off.
3. Click Save.

Note: A manual republish of Persons is required for the change to take effect on the Portal.

By default, the Pure Portal is optimized for displaying languages which run from left to right, such as English. We have now added a configuration option which helps optimize the rendering of right-to-left languages in Pure.

When enabled, the metatags in the Portal which tell your internet browser which direction language should be rendered in will be changed to "auto" ("dir=auto"). This means that for any given string of text, the browser will detect whether it is an RTL or LTR language, and optimize display based on this. We use "dir-auto" in this case, instead of "dir=rtl", because even when a Portal is set up for an RTL language, there will almost always still be text strings that need to be rendered as LTR, for example publication names.

As the decision whether to optimize text strings for RTL or LTR is made algorithmically, we advise to only enable this configuration if your Portal should contain large quantities of RTL text. Enabling unnecessarily could interfere with the normal display of LTR languages in some small cases.   

To enable RTL optimization in your Portal:

1. Go to System Settings > Right-to-left languages.
2. Toggle Enable RTL to On.

Note: A manual republish of all content types (each content type must be republished separately) is required for the change to take effect on the Portal.