Repository Tools 2 - FAQ

RT2 uses your repository as a datasource. Each Repository platform - DSpace, EPrints and Figshare - has different configuration options. To begin, go to System admin > Data sources > Data source management and locate your Repository type from the options available. Then, go to the appropriate support article by clicking on the Setup & usage guide link for guidance on how to configure your RT2 integration.

In exactly the same way as it matches publications from any other data source. Therefore, if the author data is correct and sufficiently complete, it will match harvested publications to the appropriate authors. If your repository author data contains author identifiers such as ORCIDs, Elements will use these for publication auto-claiming, as it would for any other data source.

The repository status of the record in Elements will be updated appropriately and any files will become inaccessible. The record metadata will remain as it was at the point of removal. Note that in the case of a deletion, record update may take up to a week.

You will have two repository records connected to a single Elements object. See the How to Merge article for details on how to handle these situations.

This depends on the version of your repository software and which repository platform you are using. Embargo information can be added as free text passed to your repository from the deposit process. Once the item is in the repository workflow you can apply restrictions which will be reflected in Elements in the Repository Deposit screen and the OA Monitor module.

The file name will be displayed without a hyperlink. Even when no hyperlink is displayed, Elements keeps a record of the file's URL, which is accessible in the Reporting Database through the [Publication Record File] table.

The file is hyperlinked if and only if:

1. the item's repository status is public (i.e. it is in the Live Archive); AND

2. the file is also public; AND

3. the file is not under any embargo

Yes, you will see the change in the repository data source record. This is controlled by the harvest crosswalk and the differential harvest.

For supported combinations of repository and Elements versions, you can configure this behaviour using "automated metadata updates" feature of RT2. Using a "relevance scheme", you can define which changes in Elements metadata will trigger the update process, and what publication metadata will be used to make the update. In addition, a "field authority list" in the deposit crosswalk gives you control over which repository metadata fields Elements is allowed to update, allowing you to protect your curated repository metadata.

(version information correct as of Oct 2022)

For details, see Repository Tools 2: Configuring Automatic Metadata Updates including Relevance Schemes

Your network or firewall maybe blocking this traffic, or your repository is unable to accept files. Raise a support ticket for assistance.

• During the initial deposit from Elements to your repository: once the deposit of a publication is complete, the new repository item's metadata is immediately harvested back into Elements as a new publication record alongside the other data source records for that publication.

• Full harvest: occurs every 30 days. Harvests all public items from the collections/sets/groups specified for harvest.

• Differential harvest: occurs every hour, harvests the latest metadata changes from the specified collections/sets/groups.

  • N.B. For DSpace, differential harvest is dependent on the OAI index being up-to-date. E.g. if the DSpace OAI indexer is scheduled to run nightly, changes made to items in DSpace will not be reflected in Elements until the following day.

• Refetch: occurs on a per-item basis; if the record of a known repository item has not been recently updated, Elements will refresh it with the latest metadata from the repository:

  • DSpace and EPrints: an item is refreshed after 7 days

  • Figshare for Institutions: an item is refreshed after 14 days

No but you could comment on this feature request: https://support.symplectic.co.uk/support/discussions/topics/6000062954

Whenever an publication is re-indexed (e.g. following some change to it or during a full reindex), Elements calculates and stores a hash value for it, using the rules defined in the relevance scheme. If the hash value changes, the automated metadata update process is triggered.

This is available for the following repositories, via the appropriate option in the Harvest settings on the data source configuration page:

• DSpace: "Collections to harvest". Enter the name of each collection on a new line. Use the collection name (not its handle or ID). DSpace communities cannot be entered here, only collections (i.e. the lowest level of the DSpace 'tree').

• EPrints: "Sets to harvest". Enter the name of each set on a new line. A list of available sets can be obtained from the OAI-PMH API of your EPrints repository, using the ListSets verb. Enter the setName, not the setSpec.

• Figshare for Institutions: "Groups to harvest". Enter the name of each group on a new line.

Elements will then restrict Full and Differential harvests to those collections/sets/groups.

Note that once an item has been harvested by Elements, the regular refresh cycle will continue to update its record even if the item is later moved to a collection/set/group that is not listed in this setting.

In addition, any item deposited from Elements is always harvested back immediately after the initial deposit, regardless of the collection/set/group it belongs to.

Yes: This is available for DSpace, EPrints and Figshare for Institutions. To enable this feature, check the "Allow redeposit" configuration setting for the data source in System admin > Data sources > Data source management.

The exact behaviour of the redeposit operation depends on the repository platform and version. The following is correct for the latest version of Elements at the time of writing (version 6.11, Feb 2023):

• DSpace 5/x.6.x

  • Files added to an item will be embargoed (i.e. have all resource policies removed).

  • If the item is in the workspace, it will be resubmitted to review (or to the public archive if there is no review step).

  • Optionally, item-level metadata can be added at the time of redeposit via a special field map in the deposit crosswalk.

• DSpace 7.x

  • Files added to a live, in-archive item will be embargoed (i.e. have all resource policies removed).

  • Files added to non-public items will be added with the default resource policies for the item.

• EPrints

  • New files will be added to the EPrints item as restricted files (document/security = "staffonly").

  • The format description of the added files (document/formatdesc) will contain the following text:
    "Added by {depositor full name} in a redeposit operation from Symplectic Elements".

• Figshare for Institutions:

  • Figshare embargos are set at the item level - if the item has an embargo in place, it will apply to the new file(s) as well as the pre-existing files.

  • If a review process is in place, the redeposit will trigger the review process for the revised item with the new file(s) attached. The previous version (without the new files) will remain public until the new version is approved by a reviewer.

  • If there is no review process, the new files will be added to the public item immediately.

For all platforms, it is not currently possible to include OA Location, change the reuse license or embargo period via re-deposit.

At the time of writing (Feb 2023), repository files cannot be deleted via Elements RT2. Instead, files should be deleted in the repository; RT2 harvesting will then update the Elements record to reflect the change in the repository.

UPDATE: This feature is marked as "planned" in this thread on our feature request forum. Please follow the thread for the latest updates and to contribute to the discussion around the implementation of this feature.

Deposit to DSpace 5.x and 6.x uses a combination of the DSpace SWORDv2 and REST APIs:

1. SWORDv2 call to create the item

2. REST call to add item metadata

3. REST call to add each file

4. SWORDv2 call to close the deposit

Deposit to DSpace 7.x uses the (new) REST endpoint exclusively:

1. REST call to create a new workspace item

2. REST call to add item metadata

3. REST call to add each file

4. REST call to grant the deposit licence

5. REST call to submit the item to review/live archive (depending on DSpace configuration)

This is controlled by background processes, there is a delay while these are updated. You can force an instant refetch - in the author's publication list, switch to Detailed view, find the publication and click on the Full text tab. This will prompt Elements to refresh the record with current status and data.

• Yes (from Elements 6.5.0). On the repository's data source management page, in the deposit settings select "Manage depositable types" and use the checkboxes to determine which publication types users are allowed to deposit.

• Yes, for the DSpace, EPrints and Hyrax integration. Starting with Elements 6.8.0, admins can configure the dropdown list of file versions that users select from when depositing.

For all versions:

• You can turn off the file versions dropdown so that users are not prompted to describe their files during deposit.

• You can freely alter the file versions used for determining OA compliance in OA Policy Settings (i.e. the file versions harvested from the repository are not necessarily limited to the file versions available on deposit).

Note: For Elements versions up to and including 6.7.0, the RT2 file version dropdown list is a fixed set of four options.

Note: File version is not used in the Figshare for Institutions integration.

• In Elements, mandatory fields are enforced in the input forms used to create or edit manual record metadata. When creating or editing a manual record, you won't be able to save it until the required fields are entered.

• Mandatory fields are not enforced for publication records harvested from third-party data sources or imported via the API. It is therefore possible that publications without a manual record may not have a value for a mandatory field.

• Therefore, if your repository has mandatory metadata fields which must have a value on deposit, it is possible that there may be no value for the corresponding Elements field, even if it is configured as "mandatory". In these cases, you could (a) customise your deposit crosswalk to supply a default value and/or (b) train your users to always create a manual record before depositing.

• Yes. For deposit to DSpace and EPrints, you can allow depositors to deposit using open access files from ArXiv and Europe PubMed Central (EMPC), if they are available.

• The Open Access Monitor allows you to filter by Full-Text available, to see which items have available open access full text copies.

• The crosswalk framework now allows institutions to optionally include the object privacy setting in their crosswalks if desired.

• The Deposit Crosswalk does not automatically exclude non-public data.

• The relevance framework for RT2 metadata updates natively prevents any metadata associated with non-public objects from being pushed to the repository.