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.
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.
- Profiles 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
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
# 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.
You can configure some aspects of the Profile feature in the
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.
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").
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.
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.
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.
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?
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.