Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Info

Since DSpace 7.3 a bidirectional ORCID integration is available for DSpace.  This feature allows for authentication via ORCID, as well as synchronizing data between ORCID and DSpace, via the usage of Researcher Profiles.


Info
titleAcknowledgementAcknowledgments
The ORCID integration has been was originally developed by 4Science in DSpace-CRIS, it . It is the result of years of collaboration with several institutions and the ORCID team that has helped to correct, improve and broaden the scope of the integration. We want to thank the University of Hong Kong that was the first institution to fund development activities on in this regards regard back in 2015 and the TUHH Hamburg University of Technology that have funded the initial porting of the ORCID integration to the new Angular/REST architecture introduced in DSpace 7. Last but not least, funds have been received by the DSpace community to port this feature from DSpace-CRIS to DSpace.

Table of Contents

Overview 

DSpace provides a bidirectional integration with ORCID based on the ORCID API v3.0. Both the Public ORCID API than and the Membership API are supported.

The table below summarize summarizes the supported features according to the type of ORCID API configured.

FeatureNo credentials*Public APIMember API
Authentication
 (tick) (tick)
Connect local profile to ORCID (authenticated ID)
 (tick) (tick)
ORCID Registry Lookup - import Person records(tick) (tick) (tick)
ORCID Registry Lookup - as authority(tick) (tick) (tick)
Import publication from ORCID(tick) (tick) (tick)
Push biographic data to ORCID

 (tick)
Push publications to ORCID (works)

 (tick)
Push projects to ORCID (fundings)

 (tick)

* No credentials: please note that ORCID strongly recommend recommends to apply at least for a free public free API Key as this will help to trouble-shooting shoot integration problem problems and get support from themORCID. There is also a chance to get better performance/priority over "unknown" client.

User features

Login via ORCID

Once enabled, an option to login via ORCID is provided to the user among the other authentication method methods configured in the system. The ORCID authentication doesn't allow the user to reset his password from DSpace.

Connect/Disconnect the

...

local profile to ORCID

The researcher can connect (or disconnect) his their DSpace local profile Researcher Profile with ORCID from the Person item detail page.

Image RemovedImage Added

Image RemovedImage Added


Once that a profile has been connected he they can manage his their synchronization preferences deciding what need to should be pushed to ORCID among the biographic data, the publications and projects associated with his profile, including:

  • biographic data
  • Publication (entities) linked with their Researcher Profile. (Publication entities are synced to Works in ORCID.)
  • Project (entities) linked with their Researcher Profile. (Project entities are synced to Fundings in ORCID.)

NOTE: The ORCID synchronization feature is disabled by default, even when ORCID Authentication is enabled. See Configuration section below for how to enable it.

 Image Added Image Removed

The synchronization can happen automatically over the night or manually, the . The list of information that need to should be pushed or updated from DSpace to ORCID is presented in a queue and can be manually discarded or immediately pushed by the researcher.

Import publications from ORCID

It is possible to import a publication from ORCID using the "Import from external sources" button in the home page. Once you select the Publication entity type you will be able to find ORCID as a Source and you can get the list of publications (ORCID works) that appear in an ORCID profile by searching for its ORCID iD.

 Image RemovedImage Added

Configuration

Enable the integration

All the ORCID features requires a minimal common set of properties to configure in the local.cfg 

Code Block
# Switch to production API once ready https://github.com/ORCID/ORCID-Source/tree/master/orcid-api-web#endpoints  These URLs are for testing against ORCID's Sandbox API
# These are only useful for testing, and you must first request a Sandbox API Key from ORCID
orcid.domain-url= https://sandbox.orcid.org
orcid.api-url = https://api.sandbox.orcid.org/v3.0
orcid.applicationpublic-client-id = <YOUR-url = https://pub.sandbox.orcid.org/v3.0
# Keep in mind, these API keys MUST be for the Sandbox API if you use "sandbox.orcid.org" URLs above!
orcid.application-client-id = <YOUR-SANDBOX-ORCID-CLIENT-ID>
orcid.application-client-secret = <YOUR-SANDBOX-ORCID-CLIENT-SECRET>

To enable the main integration (i.e. connect local profile with ORCID and push data to the ORCID registry) you need to be an ORCID Member, get a Member API Key and proper enable and configure the feature in DSpace.

Warning

The ORCID Synchronization features depend on other features that must be enabled: DSpace User Profile, Configurable Entities at least Person, Publication, Project & OrgUnit.

The synchronization features are classified as experimental at the time of 7.3 and it MUST be enabled manually. Due to the strict validation rules applied on the ORCID side and the absence of friendly edit UI  for the archived items in DSpace (see issues#2876), it is hard at this time to achieve an optimal UX.

In the ORCID API Credentials request form you will be asked to enter one or more redirect URLs for you application (DSpace), you will need to enter here the root URL of your REST and Angular interfaces that could eventually be different, otherwise it will be sufficient to put the URL of your angular UI. For the DSpace 7 official demo these are

Once ORCID has reviewed and approved your request, you will get from them the Client ID and Client Secret that need to be set in the local.cfg  among other properties (see below)

Code Block
# the properties below are required only for the sync / linking part (not for authentication or import)
orcid.synchronization-enabled = true
# you need to enable the orcidqueue consumer to keep track of what need to be sync between DSpace and ORCID
event.dispatcher.default.consumers = versioning, discovery, eperson, orcidqueue

Please note that by default DSpace will request permissions to READ and WRITE all the information from the ORCID profile as this will enable support for all the features. You can eventually fine-tuning that overriding the following properties, please note that if you are going to configure Public API Credential you MUST update this configuration keeping only the /authenticate  scope as all the other scopes require member API

Code Block
# The scopes to be granted by the user during the login on ORCID (see https://info.orcid.org/faq/what-is-an-oauth-scope-and-which-scopes-does-orcid-support/)
orcid.scope = /authenticate
orcid.scope = /read-limited
orcid.scope = /activities/update
orcid.scope = /person/update

The push of DSpace data (Person, Publication, Project) to ORCID is based on mappings defined in the config/modules/orcid.cfg  file, more details below in the dedicated paragraphs.



# Once you are ready to switch to Production, you need to update these settings to use ORCID's production API
# See https://github.com/ORCID/ORCID-Source/tree/master/orcid-api-web#endpoints
# orcid.domain-url= https://orcid.org
# orcid.api-url = https://api.orcid.org/v3.0
# orcid.public-url = https://pub.orcid.org/v3.0
# DON'T FORGET TO UPDATE YOUR API KEY! It must be a valid Public or Member API Key
# orcid.application-client-id = <YOUR-PRODUCTION-ORCID-CLIENT-ID>
# orcid.application-client-secret = <YOUR-PRODUCTION-ORCID-CLIENT-SECRET>


  • Enable in Production: To enable the main integration (i.e. connect a local profile with ORCID and push data to the ORCID registry) you MUST to be an ORCID Member, get a Member API Key and properly enable and configure the feature in DSpace.  See also "How do I register for Member API credentials?" from ORCID.
  • Enable in Testing: To test ORCID integration, it's possible to use the ORCID Sandbox (without being an ORCID member). However, to do so, you must request a Sandbox Member API Key. See also "How do I register a public api client?".
  • Setting the "redirect URL" in ORCID: In the ORCID API Credentials request form you will be asked to enter one or more redirect URLs for your application (DSpace). You will need to enter here the root URLs of your REST and user interfaces, which could be different. If the root URLs of both are the same, then just enter the URL of your user interface.
  • Configure the Client ID and Client Secret in DSpace: Once ORCID has reviewed and approved your request, you will get from them the Client ID and Client Secret that need to be set in the local.cfg  among other properties See the configuration examples above.

Please note that by default DSpace will request permissions to READ and WRITE all the information from the ORCID profile, as this will enable support for all of the features. You can fine-tune that by overriding the following properties. Please note that if you are going to configure Public API Credentials you MUST update this configuration keeping only the /authenticate  scope as all the other scopes require Member API.

Code Block
# The scopes to be granted by the user during the login on ORCID (see https://info.orcid.org/faq/what-is-an-oauth-scope-and-which-scopes-does-orcid-support/)
orcid.scope = /authenticate
# The below scopes are ONLY valid if you have a Member API Key. They should be commented out if you only have a Public API Key
orcid.scope = /read-limited
orcid.scope = /activities/update
orcid.scope = /person/update


To enable To enable the ORCID Authentication you need to uncomment the following line in the modules/authentication.cfg  file or adding add it to your local.cfg 

Code Block
plugin.sequence.org.dspace.authenticate.AuthenticationMethod = org.dspace.authenticate.OrcidAuthentication

Please note that you are NOT required to enable the ORCID Authentication to use the other ORCID features, including the synchronisation ones. It is also possible to use just the ORCID Authentication without enabling all the other features.

When an a user logged-loggs in via ORCID the system will attempt to reuse an existing account looking up by email, if . If none is found then a new account is created in DSpace. It is eventually possible to disable the creation of new accounts settings by setting the following property:

Code Block
authentication-orcid.can-self-register = false

Configure the push of information from DSpace to ORCID

Please note that many fields on the ORCID side are subject to validation, i.e. only values from controlled-list can be used and some fields are mandatory. The table below summarize the validation that are defined at the time of DSpace 7.3, ORCID update such rules periodically usually modifying (enlarging) the controlled-list, change to the mandatory fields can also happen


To enable ORCID Synchronization, you need to uncomment the following or add it to your local.cfg

Code Block
# the properties below are required only for the sync / linking part (not for authentication or import)
orcid.synchronization-enabled = true
# you need to enable the orcidqueue consumer to keep track of what need to be sync between DSpace and ORCID
event.dispatcher.default.consumers = versioning, discovery, eperson, orcidqueue

The push of DSpace data (Person, Publication, Project) to ORCID is based on mappings defined in the config/modules/orcid.cfg  file. You will find details below in the dedicated paragraphs.

Warning

The ORCID Synchronization features depend on other features that must be enabled: DSpace User Profile, Configurable Entities at least Person, Publication, Project & OrgUnit.

The synchronization features are classified as experimental at the time of 7.3 and it MUST be enabled manually. Due to the strict validation rules applied on the ORCID side and the absence of friendly edit UI  for the archived items in DSpace (see issues#2876), it is hard at this time to achieve an optimal UX.


Configure the push of information from DSpace to ORCID

Please note that many fields on the ORCID side are subject to validation, i.e. only values from controlled-list can be used and some fields are mandatory. The table below summarizes the validations that are defined at the time of DSpace 7.3. ORCID updates such rules periodically, usually modifying (enlarging) the controlled-list, and changes to the mandatory fields can also happen.

ORCID EntityCorresponding DSpace EntityMandatory fieldsControlled fields
PersonPerson
ORCID EntityMandatory fieldsControlled fieldsPerson

Country (iso-3166 2 code letter)

Work

Title

Type

Publication Date (>= 1900)

External Identifier (at least one)

Type (https://info.orcid.org/documentation/integration-and-api-faq/#easy-faq-2682)

Identifier.Type (https://pub.orcid.org/v3.0/identifiers)

Funding

Title

External Identifier (at least one)

Funding Agency (Organisation)

Currency if an Amount is provided

Amount.Currency (https://www.iso.org/iso-4217-currency-codes.html)Organisation

External Identifier (at least one)

Address

City

Country

See https://support.orcid.org/hc/en-us/articles/360006894674-Metadata-in-the-Funding-section

Country (iso-3166 2 code letter)

Identifier.Type (ROR, LEI, CrossRef Funder ID, RINGOLD, GRID)

To provide more meaningful message to the user DSpace implements a local validation before to try to push the record to ORCID. This validation verify the rules above so that a specific message is displaied to the user. If for any reason another errors is returned by ORCID a generic message is show to the user and the exact technical message received by ORCID is logged in the dspace.log  file and stored in the orcidhistory  table.

The local validation can be eventually turned-off, this is mainly intended as a development/debug option and should be not enabled in production

Code Block
orcid.validation.work.enabled = true
orcid.validation.funding.enabled = true

Mapping of the DSpace Person Items to ORCID Works

Metadata in a DSpace "Person" item, once that the item has been linked to ORCID by the researcher owning the ORCID profile, can be pushed to ORCID to fill specific Profile Section of the ORCID Person using the org.dspace.orcid.service.OrcidProfileSectionFactoryService   configured via this mapping bean

WorkPublication

Title

Type

Publication Date (>= 1900)

External Identifier (at least one)

Type (https://info.orcid.org/documentation/integration-and-api-faq/#easy-faq-2682)

Identifier.Type (https://pub.orcid.org/v3.0/identifiers)

FundingProject

Title

External Identifier (at least one)

Funding Agency (Organisation)

Currency if an Amount is provided

Amount.Currency (https://www.iso.org/iso-4217-currency-codes.html)
OrganisationOrgUnit

External Identifier (at least one)

Address

City

Country

See https://support.orcid.org/hc/en-us/articles/360006894674-Metadata-in-the-Funding-section

Country (iso-3166 2 code letter)

Identifier.Type (ROR, LEI, CrossRef Funder ID, RINGOLD, GRID)


To provide more meaningful messages to the user DSpace implements a local validation before trying to push the record to ORCID. This validation verifies the data using the rules above so that a specific message is displayed to the user. If for any reason another error is returned by ORCID a generic message is shown to the user and the exact technical message received by ORCID is logged in the dspace.log  file and stored in the orcidhistory  table.

The local validation can be turned off. This validation is mainly intended as a development/debug option and should be not enabled in production.

Code Block
orcid.validation.work.enabled = true
orcid.validation.funding.enabled = true


Mapping of the DSpace Person Items to ORCID Works

Metadata in a DSpace "Person" item, once that the item has been linked to ORCID by the researcher owning the ORCID profile, can be pushed to ORCID to fill the Profile Section of the ORCID Person using the org.dspace.orcid.service.OrcidProfileSectionFactoryService configured via this mapping bean:

Code Block
    <!-- Configuration of ORCID profile sections factory. 
    Each entry of sectionFactories must be an implementation of OrcidProfileSectionFactory.-->
    
Code Block
    <!-- Configuration of ORCID profile sections factory. 
    Each entry of sectionFactories must be an implementation of OrcidProfileSectionFactory.-->
    <bean class="org.dspace.orcid.service.impl.OrcidProfileSectionFactoryServiceImpl">
    	<constructor-arg name="sectionFactories">
    		<list>
    		
    			<bean class="org.dspace.orcid.model.factory.impl.OrcidSimpleValueObjectFactory">
					<constructor-arg name="sectionType" value="OTHER_NAMES" />
					<constructor-arg name="preference" value="BIOGRAPHICAL" />
					<property name="metadataFields" value="${orcid.mapping.other-names}" />
				</bean>
				
    			<bean class="org.dspace.orcid.modelservice.factory.impl.OrcidSimpleValueObjectFactoryOrcidProfileSectionFactoryServiceImpl">
					    	<constructor-arg name="sectionTypesectionFactories" value="KEYWORDS" />
					>
    		<list>
    		
    			<bean class="org.dspace.orcid.model.factory.impl.OrcidSimpleValueObjectFactory">
					<constructor-arg name="sectionType" value="OTHER_NAMES" />
					<constructor-arg name="preference" value="BIOGRAPHICAL" />
					<property name="metadataFields" value="${orcid.mapping.keywordsother-names}" />
				</bean>
				
    			<bean class="org.dspace.orcid.model.factory.impl.OrcidSimpleValueObjectFactory">
					<constructor-arg name="sectionType" value="COUNTRYKEYWORDS" />
					<constructor-arg name="preference" value="BIOGRAPHICAL" />
					<property name="metadataFields" value="${orcid.mapping.countrykeywords}" />
				</bean>
				
    			<bean class="org.dspace.orcid.model.factory.impl.OrcidPersonExternalIdentifierFactoryOrcidSimpleValueObjectFactory">
					<constructor-arg name="sectionType" value="EXTERNAL_IDSCOUNTRY" />
					<constructor-arg name="preference" value="IDENTIFIERSBIOGRAPHICAL" />
					<property name="externalIdsmetadataFields" value="${orcid.mapping.person-external-idscountry}" />
				</bean>
				
    			<bean class="org.dspace.orcid.model.factory.impl.OrcidSimpleValueObjectFactoryOrcidPersonExternalIdentifierFactory">
					<constructor-arg name="sectionType" value="RESEARCHEREXTERNAL_URLSIDS" />
					<constructor-arg name="preference" value="IDENTIFIERS" />
					<property name="metadataFieldsexternalIds" value="${orcid.mapping.researcherperson-external-urlsids}" />
				</bean>
				
    		</list>
    	</constructor-arg>
    </bean>	<bean class="org.dspace.orcid.model.factory.impl.OrcidSimpleValueObjectFactory">
					<constructor-arg name="sectionType" value="RESEARCHER_URLS" />
					<constructor-arg name="preference" value="IDENTIFIERS" />
					<property name="metadataFields" value="${orcid.mapping.researcher-urls}" />
				</bean>
				
    		</list>
    	</constructor-arg>
    </bean>

The above configuration links the above configuration link each piece of information that can be synchronized from DSpace to ORCID to with a preference that the user can manage on the DSpace side (i.e. sync of the keywords is linked to the BIOGRAPHICAL preference) and define defines which DSpace metadata will be used to fill the ORCID field. The bean reads the metadata mapping from the config/modules/orcid.cfg 

Code Block
### Other names mapping ###
orcid.mapping.other-names = person.name.variant
orcid.mapping.other-names = person.name.translated

### Keywords mapping ###
orcid.mapping.keywords = dc.subject

### Country mapping ###
orcid.mapping.country = person.country
orcid.mapping.country.converter =

### Person External ids mapping ###
##orcid.mapping.person-external-ids syntax is <metadatafield>::<type>
orcid.mapping.person-external-ids = person.identifier.scopus-author-id::SCOPUS
orcid.mapping.person-external-ids = person.identifier.rid::RID

### Researcher urls mapping ###
orcid.mapping.researcher-urls = dc.identifier.uri

...

A DSpace "Publication" item is pushed to ORCID as a "Work" using the org.dspace.orcid.model.factory.impl.OrcidWorkFactory  configured via this mapping bean:

Code Block
	<bean id="orcidWorkFactoryFieldMapping" class="org.dspace.app.orcid.model.OrcidWorkFieldMapping" >
		<property name="contributorFields" value="${orcid.mapping.work.contributors}" />
		<property name="externalIdentifierFields" value="${orcid.mapping.work.external-ids}" />
		<property name="publicationDateField" value="${orcid.mapping.work.publication-date}" />
		<property name="titleField" value="${orcid.mapping.work.title}" />
		<property name="journalTitleField" value="${orcid.mapping.work.journal-title}" />
		<property name="shortDescriptionField" value="${orcid.mapping.work.short-description}" />
		<property name="subTitleField" value="${orcid.mapping.work.sub-title}" />
		<property name="languageField" value="${orcid.mapping.work.language}" />
		<property name="languageConverter" ref="${orcid.mapping.work.language.converter}" />
		<property name="typeField" value="${orcid.mapping.work.type}" />
		<property name="typeConverter" ref="${orcid.mapping.work.type.converter}" />
		<property name="citationType" value="${orcid.mapping.work.citation.type}" />
	</bean>

that respectively read reads the mapping from the config/modules/orcid.cfg  file:

Code Block
### Work (Publication) mapping ###
orcid.mapping.work.title = dc.title
orcid.mapping.work.sub-title =
orcid.mapping.work.short-description = dc.description.abstract
orcid.mapping.work.publication-date = dc.date.issued
orcid.mapping.work.language = dc.language.iso
orcid.mapping.work.language.converter = mapConverterDSpaceToOrcidLanguageCode
orcid.mapping.work.journal-title = dc.relation.ispartof
orcid.mapping.work.type = dc.type
orcid.mapping.work.type.converter = mapConverterDSpaceToOrcidPublicationType

##orcid.mapping.work.contributors syntax is <metadatafield>::<role>
orcid.mapping.work.contributors = dc.contributor.author::author
orcid.mapping.work.contributors = dc.contributor.editor::editor

##orcid.mapping.work.external-ids syntax is <metadatafield>::<type> or $simple-handle::<type>
##The full list of available external identifiers is available here https://pub.orcid.org/v3.0/identifiers
orcid.mapping.work.external-ids = dc.identifier.doi::doi
orcid.mapping.work.external-ids = dc.identifier.scopus::eid
orcid.mapping.work.external-ids = dc.identifier.pmid::pmid
orcid.mapping.work.external-ids = $simple-handle::handle
orcid.mapping.work.external-ids = dc.identifier.isi::wosuid
orcid.mapping.work.external-ids = dc.identifier.issn::issn

in In the above configuration the "simple" properties are mapped matching the ORCID field name on the left (i.e. short-description) with the DSpace metadata that holds such information (i.e dc.description.abstract). For the ORCID Type field a special "converter" is configured so that the value of the DSpace metadata (i.e. dc.type) is mapped to the controlled-list of types accepted by ORCID (https://info.orcid.org/faq/what-work-types-does-orcid-support/). The value of the orcid.mapping.work.type.converter  matches the name of a bean defined in the config/spring/api/orcid-services.xml  

...

Finally a special treatment is needed for the external ids as this is a complex field on the ORCID side composed by of two value, values: the identifier type (from a controlled-list) and the identifier value. In this case the configuration allow to map maps a DSpace metadata field (i.e. dc.identifier.doi) to a specific identifier type (i.e. the part after :: , doi).

...

A DSpace "Project" item is pushed to ORCID as a "Funding" using the org.dspace.orcid.model.factory.impl.OrcidFundingFactory configured configured via this mapping bean:

Code Block
	<bean id="orcidFundingFactoryFieldMapping" class="org.dspace.orcid.model.OrcidFundingFieldMapping" >
		<property name="contributorFields" value="${orcid.mapping.funding.contributors}" />
		<property name="externalIdentifierFields" value="${orcid.mapping.funding.external-ids}" />
		<property name="titleField" value="${orcid.mapping.funding.title}" />
		<property name="typeField" value="${orcid.mapping.funding.type}" />
		<property name="typeConverter" ref="${orcid.mapping.funding.type.converter}" />
		<property name="amountField" value="${orcid.mapping.funding.amount}" />
		<property name="amountCurrencyField" value="${orcid.mapping.funding.amount.currency}" />
		<property name="amountCurrencyConverter" ref="${orcid.mapping.funding.amount.currency.converter}" />
		<property name="descriptionField" value="${orcid.mapping.funding.description}" />
		<property name="startDateField" value="${orcid.mapping.funding.start-date}" />
		<property name="endDateField" value="${orcid.mapping.funding.end-date}" />
		<property name="organizationRelationshipType" value="${orcid.mapping.funding.organization-relationship-type}" />
	</bean>

that respectively read reads the mapping from the config/modules/orcid.cfg  file

...

in the above configuration the "simple" properties are mapped matching the ORCID field name on the left (i.e. description) with the DSpace metadata metadatafield that holds such information (i.e dc.description). For the ORCID Type field a special "converter" is configured so that the value of the DSpace metadata (i.e. dc.type) is mapped to the controlled-list of types accepted by ORCID (https://support.orcid.org/hc/en-us/articles/360006894674-Metadata-in-the-Funding-section). The value of the orcid.mapping.funding.type.converter  matches the name of a bean defined in the config/spring/api/orcid-services.xml  the The same apply for the currency orcid.mapping.funding.amount.currency.converter = mapConverterDSpaceToOrcidAmountCurrency 

...

Finally a special treatment is needed for Funder that is a mandatory field on the ORCID side, in . In this case the mapping allow to define defines which relation is used to link the Project with the Funder (OrgUnit)

...

The following bean is used to configure the import of person records from ORCID, it . It is activated as an external source in config/spring/api/external-services.xml 

...

the mapping between ORCID Person and the DSpace Person Item is the following, currently hard-coded:

ORCIDDSpace
Name/FamilyNameperson.firstName
Name/GivenNameperson.givenName
Name/Pathperson.identifier.orcid
ORCID Profile URLdc.identifier.uri


the The following bean is instead used to configure the i mport import of publication records from ORCID (Work)

Code Block
    <bean id="orcidPublicationDataProvider" class="org.dspace.external.provider.impl.OrcidPublicationDataProvider">
        <property name="sourceIdentifier" value="orcidWorks"/>
        <property name="fieldMapping" ref="orcidPublicationDataProviderFieldMapping"/>
        <property name="supportedEntityTypes">
            <list>
                <value>Publication</value>
            </list>
        </property>
    </bean>


the The mapping of the ORCID Work metadata to the DSpace metadata is performed by the following beans bean in config/spring/api/orcid-services.xml 

Code Block
	<bean id="orcidPublicationDataProviderFieldMapping" class="org.dspace.orcid.model.OrcidWorkFieldMapping" >
		<property name="contributorFields" value="${orcid.external-data.mapping.publication.contributors}" />
		<property name="externalIdentifierFields" value="${orcid.external-data.mapping.publication.external-ids}" />
		<property name="publicationDateField" value="${orcid.external-data.mapping.publication.issued-date}" />
		<property name="titleField" value="${orcid.external-data.mapping.publication.title}" />
		<property name="journalTitleField" value="${orcid.external-data.mapping.publication.is-part-of}" />
		<property name="shortDescriptionField" value="${orcid.external-data.mapping.publication.description}" />
		<property name="languageField" value="${orcid.external-data.mapping.publication.language}" />
		<property name="languageConverter" ref="${orcid.external-data.mapping.publication.language.converter}" />
		<property name="typeField" value="${orcid.external-data.mapping.publication.type}" />
		<property name="typeConverter" ref="${orcid.external-data.mapping.publication.type.converter}" />
	</bean>

that respectively read reads the mapping from the config/modules/orcid.cfg  file.

Info
Please note that such mapping is separated from the mapping used to push information from DSpace to ORCID but usually, as provided in the default configuration, the mapping should be the same.


Code Block
### Work (Publication) external-data.mapping ###
orcid.external-data.mapping.publication.title = dc.title

orcid.external-data.mapping.publication.description = dc.description.abstract
orcid.external-data.mapping.publication.issued-date = dc.date.issued
orcid.external-data.mapping.publication.language = dc.language.iso
orcid.external-data.mapping.publication.language.converter = mapConverterOrcidToDSpaceLanguageCode
orcid.external-data.mapping.publication.is-part-of = dc.relation.ispartof
orcid.external-data.mapping.publication.type = dc.type
orcid.external-data.mapping.publication.type.converter = mapConverterOrcidToDSpacePublicationType

##orcid.external-data.mapping.publication.contributors syntax is <metadatafield>::<role>
orcid.external-data.mapping.publication.contributors = dc.contributor.author::author
orcid.external-data.mapping.publication.contributors = dc.contributor.editor::editor

##orcid.external-data.mapping.publication.external-ids syntax is <metadatafield>::<type> or $simple-handle::<type>
##The full list of available external identifiers is available here https://pub.orcid.org/v3.0/identifiers
orcid.external-data.mapping.publication.external-ids = dc.identifier.doi::doi
orcid.external-data.mapping.publication.external-ids = dc.identifier.scopus::eid
orcid.external-data.mapping.publication.external-ids = dc.identifier.pmid::pmid
orcid.external-data.mapping.publication.external-ids = dc.identifier.isi::wosuid
orcid.external-data.mapping.publication.external-ids = dc.identifier.issn::issn

...

  • via an ORCID lookup authority available for a DSpace repository that are is not using Configurable Entities
  • via a relation among the research output item (Publication, etc.) and a Person Item bind bound to the ORCID Person External Source defined in the previous paragraph

...


Troubleshooting & common issues

The trouble-shooting troubleshooting guide from ORCID can help as well https://info.orcid.org/documentation/integration-guide/troubleshooting/

I'm having trouble

...

testing the ORCID integration

...

. What should I check?

Please double check the documentation and the other FAQ FAQs to be sure to that you have followed all of the instructions to enable the integration correctly. If you still have trouble reach , contact the DSpace tech community via email or slack trying to provide providing as much details detail as possible. If the issue is related to the synchronization of DSpace local data with ORCID it would be useful to share information about the content of your orcidhistory  table and any relevant message that you could have in the dspace.log  file.

I cannot find the ORCID features described in this page in my installation

The ORCID features must be enabled by hand changing some configuration file, please refer to the Enable the integration section paragraph above in the page

I'm unable to authenticate via ORCID

If you have enabled correctly the ORCID authentication feature and you are able to start the OAuth flow with ORCID but get a failure when you are redirected back to DSpace it could be due to privacy settings on your ORCID record. The DSpace ORCID authentication requires that you release an email address to match your ORCID account with a DSpace account or to create a new one at your first login. Make your your ORCID account email address public or visible to trusted party. This is often not the case for freshly created account on ORCID.

...

message that you could have in the dspace.log  file.

I cannot find the ORCID features described by this page in my installation

The ORCID features must be enabled by changing some configuration files. Please refer to the Enable the integration section above.

I'm unable to authenticate via ORCID

If you have correctly enabled the ORCID authentication feature and you are able to start the OAuth flow with ORCID but get a failure when you are redirected back to DSpace, it could be due to privacy settings on your ORCID record. The DSpace ORCID authentication requires that you release an email address to match your ORCID account with a DSpace account or to create a new one at your first login. Make your ORCID account email address public or visible to trusted parties. This is often not the case for a freshly created account on ORCID.

If you are encountering this issue, you'll see a message like this in your "dspace.log" file on the backend:

Code Block
2022-08-04 11:43:42,124 ERROR unknown unknown org.dspace.authenticate.OrcidAuthenticationBean @ An error occurs registering a new EPerson from ORCID
java.lang.IllegalStateException: The email is configured private on orcid


After logging in via ORCID, a new DSpace account was created instead of using my existing DSpace account

Currently, the ORCID integration with DSpace relies on a matching email address to find your existing account.  If your ORCID account and DSpace account have different email addresses associated with them, then it is possible that a new (duplicative) user account will be created. 

I'm having trouble creating test accounts on ORCID to experiment with the features

Please refer to the ORCID trouble-shooting guide https://info.orcid.org/documentation/integration-guide/troubleshooting/ a A frequent mistake working with the ORCID sandbox environment is to forget that only email address addresses @mailinator.com are allowed for account created on the sandbox. Remember to validate your email address once the account as been created visiting the online inbox at mailinator.com

...

When you use public ORCID API credentials you can only use a subset of the integration features (check) moreover . Moreover you need to limit the scopes (permissions) requested to the user via the ORCID authentication to the /authenticate  scope. Please check the Enable the integration section paragraph above in the page.

I don't find my publications looking up for my ORCID iD

Please check "config/modules/orcid.cfg" (or your local.cfg) to see if the system has been properly configured to use the production ORCID API, there . There is a chance that your installation is still configured to use the ORCID Sandbox that is appropriate for the testing and developement development phase of the integration. The ORCID sandbox doesn't contain the same data than as the publication Public environment.

I cannot push all my publications, only few or none of them are listed in the queue

Please double check that the orcidqueue  consumer has been enabled consumer has been enabled (in dspace.cfg or local.cfg) and that the orcid settings of your profile has have the "All publications" checkbox flagged. ORCID features require the use of the new Configurable Entities. Only Publication item are synchronized with ORCID, legacy ; simple "untyped" items Items will not be synchronized. Please consider to convert your legacy collection to "Publication" collection and set a dspace.entity.type = Publication  metadata on your legacy items.

Push of publications to ORCID fails

This is usually due to validation errors. ORCID could complain about missing mandatory fields or invalid values for field fields that are linked to a controlled-list. Please check the table in the Configure the push of information from DSpace to ORCID and the Mapping of DSpace Publication items to ORCID Works paragraph to solve this.  Your dspace.log file may also provide useful error messages.

Push of projects to ORCID fails

This is usually due to validation errors. Pays attention to the information in the linked Funding Agency Organisation as well because validation failure on the Funding Agency data will prevent to push the whole fundingMake sure that all required metadata fields exist on the Project Entity and any linked OrgUnit Entities. ORCID could complain about missing mandatory fields or invalid values for field fields that are linked to a controlled-list. Please check the table in the Configure the push of information from DSpace to ORCID and the Mapping of DSpace Project items to ORCID Funding paragraph to solve this. Your dspace.log file may also provide useful error messages.