Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: removed XMLUI-only warning as PR#2710 ported to JSPUI


Info
titleORCID API version compatibility

Please note that ORCID API 1.2 was turned off on August 1, 2018. To use the current ORCID API 2.x, you will need DSpace 5.9 or DSpace 6.3 or newer. Details: DS-3447.

Table of Contents
minLevel2
outlinetrue
stylenone

...

Enabling the ORCID authority control


Warning
titleJSPUI XMLUI Theme Support

In DSpace 5.0 , the functionality only includes user interface functionality for the DSpace XML User Interface. 

Warning
titleXMLUI Theme Support

In DSpace 5.0 the functionality only adds adds support for the XMLUI Mirage and Mirage 2 themes. Older XMLUI themes including Kubrick, Reference and Classic are currently unsupported.

If you wish to enable this feature, some changes are required to the dspace.cfg file. The first step is to activate the authority as a valid option for authority control, this is done by adding/setting an additional plugin in the  plugin plugin.named.org.dspace.content.authority.ChoiceAuthority property. An example of this can be found below.

...

The feature relies on the following configuration parameters in dspace.cfg. To activate the default settings it suffices to remove the comment hashes ("#") for the following lines. See the section at the bottom of this page what these parameters mean exactly and how you can tweak the configuration.

...

Code Block
event.dispatcher.default.consumers = authority, versioning, discovery, eperson, harvester

Importing existing authors & keeping the index up to date

...

Running this script again will update the index and keep the index clean. For example if an author occurs in a single item and that item is deleted the script will need to be run again to remove it from the index. When run again it will remove all records that no longer have a link to existing authors in the database.

 

Usage in DSpace


Submission of new DSpace items - Author lookup

The submissions forms have not changed much. The only thing you can notice is an extra button next to the input fields for the author names. Next to the Add button, which is common for all repeatable fields, there is the Lookup & Add button.

Image RemovedImage Added

It's by clicking on that button that the Look-up User Interface appears. If an author name was filled in but not added yet, the Lookup User Interface will immediately perform a search for that name. Otherwise the search field remains empty and a list of known authors is displayed. The list of authors is updated as you type in the search box.

...

The authors retrieved from ORCID have their name italicized and they're listed after the authors that are found in the repository.

Image RemovedImage Added

Click on one of these names to see more information about them. The message "There's no one selected" will vanish, making room for the author's information. The available information can vary: Authors imported from ORCID have an orcid where the others do not. Authors that have been added without look-up only show their last name and first name.

...

Clicking the Lookup button brings back the Lookup User Interface. This works just the same way as in the submission forms.

Image RemovedImage Added

Editing existing items using Batch CSV Editing

Instructions on how to use the Batch CSV Editing are found on the Batch Metadata Editing documentation page.

Image RemovedImage Added

ORCID Integration is provided through the Batch CSV Editing feature with an extra available headers "ORCID:dc.contributor.author". The usual CSV headers only contain the metadata fields: e.g. "dc.contributor.author". In addition to the traditional header, another dc.contributor.author header can be added with the "ORCID:" prefix. The values in this column are supposed to be ORCIDs.

Image RemovedImage Added

For each of the ORCID authors a lookup will be done and their names will be added to the metadata. All the non-ORCID authors will be added as well. The authority keys and solr records are added when the reported changes are applied.

Image Removed

 Image Added


Storage of related metadata

...

In practice the cache is provided by an apache solr server. When a look-up is made and an author is chosen that is not yet in the cache, a record is created from an ORCID profile and added to the cache with the list of related metadata. The value of the Dublin Core metadata is based on the first and last name as they are set in the ORCID profile. The authority key for this value links directly to the solr document's id. DSpace does not provide a way to edit these records manually.

Image RemovedImage Added

The information in the authority cache can be updated by running the following command line operation:

Command used:
[dspace]/bin/dspace 
[dspace]/bin/dspace dsrun
dsrun org.dspace.authority.UpdateAuthorities
Argumentsdescription
-iupdate specific solr records with the given internal ids (comma-separated)
-hprints this help message

This will iterate over every solr record currently in use (unless the -i argument is provided), query the ORCID web service for the latest data and update the information in the cache. If configured, the script will also update the metadata of the items in the repository where applicable.

The configuration property can be set in config/modules/solrauthority.cfg, or overridden in your local.cfg: (see Configuration Reference).

Code Block
solrauthority.auto-update-items = false | true

When set to true and this is script is run, if an authority record's information is updated the whole repository will be scanned for this authority. Every metadata field with this authority key will be updated with the value of the updated authority record.

Configuration

...

with the value of the updated authority record.

Configuration

In the Enabling the ORCID authority control section, you have been told to add this block of configuration.

Info
titleNOTE: for DSpace 6x you can use local.cfg for these

For all of the configuration options described below, you can use either dspace.cfg or local.cfg. Either will work. It is possible that, when you compile your code with Maven, and you have tests enabled, your build will fail. DSpace unit tests utilize parts of dspace.cfg, and the configuration options you will utilize below are known to cause unit test errors. The easiest way to avoid this situation is to use the local.cfg file.


Code Block
solr.authority.server=${solr.server}/authority
choices.plugin.dc.contributor.author = SolrAuthorAuthority
choices.presentation.dc.contributor.author = authorLookup
authority.controlled.dc.contributor.author = true
authority.author.indexer.field.1=dc.contributor.author

...

  • With the authority.controlled property every metadata field that needs to be authority controlled is configured. This involves every type of authority control, not only the fields for ORCID integration.
  • The choices.plugin should be configured for each metadata field under authority control. Setting the value on SolrAuthorAuthority tells DSpace to use the solr authority cache for this metadatafield, cfr. Storage of related metadata.
  • The choices.presention should be configured for each metadata field as well. The traditional values for this property are select|suggest|lookup. A new value, authorLookup, has been added to be used in combination with the SolrAuthorAuthority choices plugin. While the other values can still be used, the authorLookup provides a richer user interface in the form of a popup on the submission page.
  • The browse indexes need to point to the new authority-controlled index: webui.browse.index.2 = author:metadata:dc.contributor.*,dc.creator:text should become webui.browse.index.2 = author:metadataAuthority:dc.contributor.author:textauthority
  • More existing configuration properties are available but their values are independent of this feature and their default values are usually fine: choices.closed , authority.required, authority.minconfidence .

For the cache update script, one property can be set in config/modules/solrauthority.cfg:

Code Block
auto-update-items = false | true

...

Code Block
event.dispatcher.default.consumers = authority, versioning, discovery, eperson, harvester

Without the consumer there is no automatic indexing of the authority cache and the metadata will not even have authority keys.

...

To fix this, open the file at config/spring/api//orcid-authority-services.xml and find this spring bean:

...

The fields with data coming directly from ORCID are: first_name, last_name, name_variant, orcid_id, label_researcher_url, label_keyword, label_external_identifier, label_biography, label_country. The field all_labels contains all the values from the other fields starting with "label_".

How can I index additional fields in the authority cache?

There is currently no configuration to control which fields are indexed. The only way to achieve this is to modify the source code.

List of the files at work for this job:
config/spring/api/orcid-authority-services.xml: OrcidSource contains the URL for orcid's REST API.
org.dspace.authority.orcid.Orcid makes the REST call
+ org.dspace.authority.orcid.xml.XMLtoBio converts the received XML to a java object (Bio).
+ org.dspace.authority.orcid.model.Bio
+ org.dspace.authority.orcid.OrcidAuthorityValue#create(org.dspace.authority.orcid.model.Bio) inserts all the values from Bio into the AuthorityValue subclass.
+ org.dspace.authority.orcid.OrcidAuthorityValue#getSolrInputDocument defines what's included in solr.

The files preceded with a '+' would be necessary to modify to add more info into the cache.

How can I use the information stored in the authority cache?

The look-up UI is currently the only place this information is sent to. However just a limited number of fields are sent. The place in the source code to modify to get more fields there is org.dspace.authority.orcid.OrcidAuthorityValue#choiceSelectMap. This is also documented in the readme of the org.dspace.authority package.

...

In short: authority keys that exist prior to enabling the solrauthority are kept. They just won't show in the look-up until they are indexed.

Where can I find the URL that is used to lookup ORCIDs?

It is found in the config/spring/api/orcid-authority-services.xml configuration file. Look for the <bean name="OrcidSource">, which is initialized with a URL of http://pub.orcid.org