SciLifeLab Data Repository Reviewing Guidelines
This page outlines the steps and considerations followed by the institutional reviewers from SciLifeLab Data Centre when an item is submitted for publication in the SciLifeLab Data Repository.
Reviewing is the act of approving or rejecting a submitted item before it becomes publicly available. Your role as a reviewer is to:
- Evaluate the findability, accessibility, reusability, and overall completeness of submitted items within maximum one week
- Provide feedback to submitters when needed
- Complete the publication process
View review requests
When a user chooses to publish an item in the SciLifeLab Data Repository, an email is automatically sent to all institutional reviewers of the repository.
To view items for review, log in to the SciLifeLab Data Repository using your institutional credentials. Click on the profile badge on the top right corner of the page to display a drop-down menu, and select Review requests. You will then see all open review requests, whether they have been assigned to you, someone else or no one. You can opt to view only your assigned requests and sort by newest or oldest first. The number you see in the menu displays unassigned, open requests. By default, the pool shows all the requests even if they are assigned already.
Assign a reviewer
To process an item submitted for review, select the item and assign yourself as the reviewer. As an institutional reviewer, you can either assign the request to yourself or to another institutional reviewer. For items that have a new version or were processed previously, it is advisable to assign the same reviewer to all versions, whenever possible.
Once a reviewer has been assigned to review an item, they will review the item according to the checks outlined below.
Item revision
The item revision is divided into the following four parts:
- Check the item submission type
- Check the item files
- Check the item information (metadata)
- Check the item submitter information
Check the submission type
The different submission types in the system can be divided into items with or without files. For an item with files, the files can be published openly, under embargo or under restricted access. When it comes to items without files there are two options; metadata record and linked file item.
✓ The submission type matches the item content.
Check the item files
The following checks are only relevant to the submission type “item with files”.
✓ The item includes a README file containing the following information:
– DOI of the item
– Description
– Author(s)
– License
– Date of the last update
✓ The item includes a manifest file listing all uploaded files.
✓ All files listed in the manifest file are uploaded to the item.
When an item only has a single file and a README file a manifest file is not required. A README file is always required, regardless of the number of files. Note that a ZIP file is not considered a single file.
Zip archives
Zip archives created on macOS often contain hidden system files that are not part of the research data. The most common are:
.DS_Store— macOS folder metadata files__MACOSX/— a hidden folder created automatically when zipping on macOS._*— macOS resource fork copies of data files
To check whether a zip archive contains hidden macOS files, run the following command in the terminal:
unzip -l archive.zip | grep -E '__MACOSX|\.DS_Store|/\._'
If the command returns any output, the archive contains hidden files.
✓ Zip archives do not contain .DS_Store files, __MACOSX/ folders, or ._* resource fork files.
If hidden files are found, contact the depositor and ask them to re-create the archive using the following command, which excludes macOS system files:
zip -r YourArchive.zip YourFolder/ -x "*.DS_Store" -x "*/__MACOSX/*" -x "*/._*"
Once the depositor has uploaded a clean archive, ask them to delete the old one.
An automated scan tool is available for checking hidden macOS files across multiple published items and generating outreach emails in bulk. See the Automated review process documentation for details.
Check the item information (metadata)
The purpose of filling out the metadata form thoroughly is to maximize the reusability of the item. Once an item is published on the SciLifeLab Data Repository it should be self-explanatory. The SciLifeLab Data Repository should be used as a catch-all space, i.e. everything that is connected to the submitted item should also be submitted to or linked to here.
Item title
✓ The title is meaningful and doesn’t contain underscores, bold formatting or file extensions.
Group
✓ If you have doubts about the group membership, consult the submitter. If the item belongs to a group project, it should have the same group affiliation as the project.
When editing the group belonging of an item the current review request will be archived and a new request will be created. The reviewer will then need to assign themselves to that review request once again.
Item type
✓ The uploaded item is labeled with the correct item type.
Authors
✓ The hyperlinked authors have their ORCID assigned
✓ If only one author is listed, ask if the submitter wants to add additional authors.
Categories
Keywords
✓ The keywords are correctly spelled. If you have doubts about the spelling, consider contacting the submitter.
✓ If a keyword is an abbreviation, make sure that the full name is added in the description part of the item.
✓ The item has at least three keywords.
Description
✓ The description is somewhat sufficient for reusability of the item.
✓ The abbreviations used in the description are explained (full name written out).
✓ The description does not contain custom font formatting.
Funding
✓ If the grants are not hyperlinked, check if they appear in the Dimension database by typing the grant number in manually and see if a dropdown menu appears. Note that pasting in grant information or typing in the grant name may not trigger an automatic search of the Dimensions database.
Related materials
Licence
✓ The right licence was selected based on the item type ( e.g software vs dataset).
✓ If the item is a metadata record only, the licence should be “Restricted Access“.
Publisher
✓ If the item is a dataset, the publisher must be the research principal (forskningshuvudman).
Contact email
This is a mandatory field that should be filled with the email address of the person to whom questions about the item should be directed.
Access request email (applies only for metadata records)
✓ For items other than metadata records, this field is left empty.
✓ If SciLifeLab Data Centre’s email is listed as access request email, confirm with the submitter that the files are located on Bianca.
SciLifeLab acknowledgement
Check the item submitter information
✓ The submitter has their ORCID connected to their account as this is recommended.
✓ The submitters name doesn’t include non-alphabetic characters.
Reviewer’s feedback
As a reviewer, after you have checked the item and its metadata, you will be given four options:
Editing
Occasionally, a reviewer may detect small ‘errors’ in the metadata that can be edited directly by the reviewer without consulting the submitter. If you change some of the metadata, please use the Save button from the Edit item tab before approving. Note! If you do not save the changes, you will approve the previous version.
These minor changes applies to, but is not limited to, the following situations:
- changing item group
- changing item type
- correcting minor typos in description or title
- add full name keyword for abbreviations explained elsewhere
- linking grants (as described under Funding)
- adding related materials
- changing licence to restricted access for metadata records
- removing access request email when files are uploaded
- removing access request email for items using the request access functionality
Comment
This option applies when improvements are required to be done by the submitter before publication. Tick the Notify owner by email box and the comment will be sent to the submitter of the item by email. The submitter can then reply to this email. This way, the comments can be discussed in order to make adjustments required before approval.
Decline
This option is relevant when the item, at least in its current state, is unsuitable for publication on the repository. This includes items sent for review even though the submitter is currently not looking to publish it. Other times you may need to decline an item for which no response to reviewers comments has been received from the submitter after five weeks.
When the reviewer need to decline an item, the reviewer should choose the option Decline. Choosing this option will open a modal providing a text box for a message to the submitter. The reviewer should add an explanation and encourage re-submission. After you have added a message to the submitter you can click on Decline and return. The submitter will be notified of this by email.
Note! Declining an item will not affect the item in anyway other than the status of it.
Publish
When the reviewer is happy with both the item and its metadata, the reviewer should choose the option Approve. Choosing this option will open a modal providing a text box for a message to the submitter. After you have added a message to the submitter you can click on Approve and publish. The submitter will be notified of this by email.
When publishing items in a project, remind the submitter to make the project public. This is only possible when at least one of the items in the project has been published.