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

Download the checklist as .pdf here Download

Download the checklist as .docx here Download

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 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.

An example of a README file can be found here Download

An example of a manifest file can be found here Download

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

This is a mandatory field where a title for the submitted item should be entered. The title should have an understandable scientific meaning, strive for an informative yet concise title. Make sure that the title is meaningful for someone without prior knowledge of the item. Avoid using underscores in the title as it can reduce the findability of an item.

✓ The title is meaningful and doesn’t contain underscores or file extensions.

Group

This is a mandatory field where a group is chosen for the item. The purpose of this field is to connect the item with the correct research group, SciLifeLab platform or unit where applicable. If there are no group preferences, choose the repository main group “Science For Life Laboratory”. Each group receives its own URL. This URL can then be referenced from the research group, platform or units own web page. The submitter can contact the SciLifeLab Data Centre figshare@scilifelab.se in order to suggest the creation of a new 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

This is a mandatory field where the submitter can select what kind of item is being submitted.

The following item types can be uploaded to the SciLifeLab Data Repository:

Book. Books are generally long-form documents, a specialist work of writing that contains multiple chapters or a detailed written study.

Conference Contribution. Any type of content contributed to an academic conference, such as papers, presentations, lectures or proceedings.

Data management plan. Data management plans are an integral part of a research venture, describing what data will be collected or created and how, and also the means by which it will be shared and preserved.

Dataset. Datasets usually provide raw data for analysis. This raw data often comes in spreadsheet form, but can be any collection of data, on which analysis can be performed.

Educational resource. Any type of content useful for teaching, learning or research in an educational context.

Figure. Figures are generally photos, graphs and static images that would be represented in traditional pdf publications.

Journal Contribution. Any type of content formally published in an academic journal, usually following a peer-review process.

Media. Media is any form of research output that is recorded and played. This is most commonly video, but can be audio or 3D representations.

Model. A formal representation of any system, entity, phenomenon or structure useful in the research endeavour.

Online Resource. Any type of resource available online.

Peer review. The evaluation of a scholarly work, usually performed before formal publication by a number of field experts.

Poster. Poster sessions are particularly prominent at academic conferences. Posters are usually one frame of a Powerpoint (or similar) presentation and are represented at full resolution to make it possible to zoom in.

Preprint. Preprints are manuscripts made publicly available before they have been submitted for formal peer review and publication. They might contain new research findings or data. Preprints can be a draft or final version of an author’s research but must not have been accepted for publication at the time of submission.

Presentation. Academic presentations can be uploaded in their original slide format. Presentations are usually represented as slide decks. Videos of presentations can be uploaded as media.

Registration. Description of a research project, including, for example, the hypotheses, data collection plans, or scripts, provided before any actual experiment or analysis is performed.

Software. Code as a research output can either be uploaded directly from your computer or through the code management system GitHub. Versioning of code repositories is supported.

Thesis. In order to distinguish essays and pre-prints from academic theses, we have a separate category. These are often much longer text-based documents than a paper.

Workflow. Resource describing protocols, procedures, methods or activities part of a scientific experiment.

✓ The uploaded item is labeled with the correct item type.

Authors

This is a mandatory field where the submitter can add the authors of the item. Every person that has been involved in the creation of the item should be added here; adding all of the authors makes the item more findable. When uploading on behalf of someone else, the submitter can remove themselves as an author.

✓ The hyperlinked authors have their ORCID assigned

✓ If only one author is listed, ask if the submitter wants to add additional authors.

Keywords

This is a mandatory field where the submitter can add keywords to the item. The keywords can be more specific than the categories and should be used as a means to make the item more findable. Facilities submitting an item are encouraged to include the name of the facility as a keyword. There is no upper limit of the number of keywords, but remember to keep the keywords accurate and relevant. In order to increase interoperability of the item the keywords should be written in a formal, accessible, shared and broadly applicable language for knowledge representation.

It is a free-text field and so special attention should be paid to the correct spelling of keywords. Misspelling keywords will decrease the findability of the item. Searches based on keywords are not case sensitive.

✓ 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

This is a mandatory, free-text field where a description of the item can be added. Ideally, the item should be self-contained and a user should be able to enter the item directly and find all of the information required to be able to understand and/or use the content e.g. reuse the data. For someone interested in the item it can be informative to know the purpose of the item, e.g. why was it generated/produced. In this field, information about specific software needed to open a file and the version of the software used by the submitters should be stated, along with a URL or persistent identifier (PID) to this software.

✓ The description is somewhat sufficient for reusability of the item.

✓ The abbreviations used in the description are explained (full name written out).

Funding

This is a non-mandatory field that can be used to add funding information related to the materials in this item. One or several funders and/or grant numbers can be added. When typing a grant number the system will automatically search the Dimensions database for the grant. If the information is found, a hyperlink will be generated to the Dimensions page.

✓ 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.

This is a non-mandatory field where materials related to the item can be listed (e.g. DOI of the associated manuscript). For each related material added, the following information can be stated:

Identifier (mandatory)
Title (non-mandatory)
Identifier type (mandatory)
Relation type (mandatory)

For each related material the submitter can also choose for it to show as a separate “call-out” box by ticking Show in linkout area.

Licence

This is a mandatory field where a licence for the item is stated. A licence normally limits how the item can be reused and altered, in what context it can be used and how the creator should be credited. It is recommended that the licence selected be as open as possible. The appropriate licence can sometimes be specified by the funder, the publisher or institutional policies.

Available licences:

✓ 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

This is a mandatory field where the submitter should state a publisher. The publisher can be, for instance, the research principal (forskningshuvudman) or the university, the institute or the unit with which the submitter is affiliated.

✓ If the item is a dataset, the publisher must be the research principal (forskningshuvudman).

Access request email (applies only for metadata records)

When uploading a metadata record, the submitter should fill out the access request email field to specify where file requests could be sent. If the built in request access functionality is being used, this field should not be filled out.

✓ 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.

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.

SciLifeLab acknowledgement

This is a non-mandatory field in which the submitter can acknowledge the involvement of a SciLifeLab platform, infrastructure unit, or central function (e.g. Data Centre, Training Hub). The submitter can select relevant option(s) from the drop-down menu. Please contact SciLifeLab Data Centre in order to request additions to the options in the list.

The purpose of this field is to give credit to platforms, units, and/or functions that were involved in the work. It is not intended as a general acknowledgements section, as one might exact in a traditional publication. Any individuals involved in the work should instead be given credit by being listed in the “Authors” field.

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
Comment
Decline
Approve

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.