Contribute to the DSpace Development Fund

The newly established DSpace Development Fund supports the development of new features prioritized by DSpace Governance. For a list of planned features see the fund wiki page.

The DSpace Researcher Profile feature has been introduced in DSpace 7.3 to support the ORCID Integration work but can be used alone. It is turned off by default and must be enabled manually

A DSpace Researcher Profile is a special Person Entity (item) that is linked with exactly one EPerson (DSpace account). This linked EPerson owns the profile (Person Item), including having WRITE permission on it. The link between the Person Item and the EPerson is managed in the Person's dspace.object.owner metadata field. This field is configured to hold authority values and will contain the UUID of the EPerson that owns the profile.

Here a summary of the key concepts & requirements of the feature:

  • Profiles require Configurable Entities to be enabled, as every Researcher Profile is represented by a Person Entity.
  • A profile can be linked to only one EPerson (user account). That EPerson has full rights to manage the profile, including whether the profile is publicly visible or private.
  • Optionally, Profiles can be synchronized (or initially created) via ORCID Integration.

When the feature is enabled, the user can create a researcher profile from his Profile (account page)

If a Person Item already exists in the system, matching the account email address, this Person Item is offered to the user:

Once a profile has been created or claimed, the user can make it public (Anonymous READ) or private:

By default, deletion of the researcher profile does NOT delete the corresponding Person Item. Instead, it just unlinks the Person Item from the EPerson account. This behavior can be changed as specified in the Advanced configuration section below.

Enable the feature

To enable the feature you need to set the following property (uncommenting it in the config/modules/researcher-profile.cfg  or adding it to the config/local.cfg )

researcher-profile.entity-type = Person

You can specify a different Entity Type for the item that can be used as profile. This is an advanced setting -- change it only if you know what are you doing and have implemented specific customisation.

You need to enable also the EPerson authority for the dspace.object.owner. Uncomment the following lines in the config/modules/authority.cfg:

# Configuration settings required for Researcher Profiles
# These settings ensure "dspace.object.owner" field are indexed by Authority Control
choices.plugin.dspace.object.owner = EPersonAuthority
choices.presentation.dspace.object.owner = suggest
authority.controlled.dspace.object.owner = true

Last, you need to ensure that at least one Collection is configured to accept Person entities.  Only EPersons having the submission right in such a Collection will be able to create profiles.  There are many possibilities for using these settings to control who may or may not create a profile.

Advanced configuration

You can configure some aspects of the Profile feature in the config/modules/researcher-profile.cfg 

Property:

researcher-profile.entity-type

Example Value:

Person

Informational Note:

The type of Entity to use for Researcher Profile items. By default, the Person Entity is used, as this is provided out-of-the-box in DSpace.  This would only need to be modified if you have created a heavily customized Configurable Entities data model which does NOT include Person.

Property:

researcher-profile.collection.uuid

Example Value:

[collection-uuid]

Informational Note:

UUID of the Collection where all Researcher Profiles should be created by default.  This Collection MUST be configured to accept Person Entities (or the entity type specified in "researcher-profile.entity-type").

By default this is UNSPECIFIED. The default behavior is that the person's Researcher Profile will be created in the Collection in DSpace which is configured to accept Person Entities and where the user has permissions to submit.  If multiple Collections of this type are available, then the first one found will be used.

Property:

researcher-profile.hard-delete.enabled

Example Value:

false

Informational note

Whether to enable "hard delete" when a Researcher Profile is deleted by an EPerson.  When "hard delete" is enabled (set to true), then anytime an EPerson deletes their Researcher Profile, the underlying Person Entity will be deleted (i.e. this acts as a permanent deletion).  When "hard delete" is disabled (set to false, the default value), then anytime an EPerson deletes their Researcher Profile, it will simply be "unlinked".  In other words, the underlying Person Entity will be kept in the system.

Property:

researcher-profile.set-new-profile-visible

Example Value:

false

Informational note

Whether to make a new Researcher Profile "visible" (i.e. allow anonymous access) on creation.  When set to "false" (default value), a newly created Researcher Profile will only be accessible to the EPerson who created it. That EPerson may chose to make to visible (i.e. allow anonymous access) at a later time.  When set to "true", a newly created Researcher Profile will be immediately accessible to anonymous users.  But, the EPerson who created it may chose to hide it (i.e. disallow anonymous access) at a later time.

Troubleshooting

I cannot find this feature

The feature needs to be enabled explicitly. Please follow the instruction in the Enable the feature section above.

The users sees an error when they try to create their profile

The feature requires that the Person entity be configured in the data model (see Configurable Entities) and the user must have permission to submit in at least one collection configured to accept Person entities. Please double check that the EPersonAuthority is bound to the dspace.object.owner  metadata -- see the Enable the feature section above.

  • No labels

3 Comments

  1. Mark H. Wood

    I see an implication that there must be at least one Collection which is configured to accept Person entities and which allows (some) users to submit to it.  But this is never made explicit, nor is it explained how to so configure the Collection.

    Some discussion would also be welcome, of how this feature envisions sites using these controls.  Is it thought that normally a submitter's Person will be stored with his submissions?  Might a site create a single People collection to hold them all, and why?  Or a People collection in each Community? why?

    1. Tim Donohue

      Mark H. Wood : You are correct, there must be at least one Collection which accepts Person Entities.   This Collection must be configured to support the "Person" Entity Type as described in the Configurable Entity Docs: Configurable Entities#3.ConfigureCollectionsforeachEntitytype

      How sites chose to store their Person Entities is up to them.  But, it would be possible to put them all into a single Collection, or alternatively have a Person Collection per Community (e.g. if every Department/College at an institution is a Community, it may make sense to have a single Person Collection for all the faculty/staff in that Department/College).   Overall, though, I do expect there to be more discussion about best practices around Entities & their Collections in general in the future. As we know Entities are such a new concept that there are no formal best practices built up yet.

  2. Paulo Graça

    I've just created this Issue: https://github.com/DSpace/DSpace/issues/8909
    I think it makes sense (for the explained reasons) to have the binding of an eperson and the item based on a configurable field instead of always using the person's email for that.

All content on the LYRASIS Wiki is licensed under the CC BY (Attribution) license, unless otherwise noted.