SciLifeLab Data Repository Reviewing Guidelines

Reviewing is the act of approving or rejecting an submitted item, with feedback, before it becomes publicly available. The SciLifeLab Data Repository has a team of institutional reviewers consisting of members from SciLifeLab Data Centre.

View review requests

When a user chooses to publish an item on the SciLifeLab Data Repository, an email is automatically sent to every reviewer of the repository. All reviewing requests can be found in the reviewing pool from the reviewer account.

To view items for review, click on the dropdown menu and select Review requests. You will then see all open review requests, whether they’ve been assigned to you or not. 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 through 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.

Once a reviewer has been assigned to review an item they will review the item according to the checks outlined below.

The reviewing checklist can be downloaded here

Check the uploaded item

✓ Check if the item appears to contain human data. Consider contacting the submitter if you have any doubts regarding this.

✓ Does the item include a README file

✓ Does the README file include a DOI to the item

✓ Does the item include a manifest file

An example of a README file can be found here

An example of a manifest file can be found here

Check the items 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.

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.

✓ Check that the title is meaningful and doesn’t contain underscores or file extensions.

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. You can remove yourself as an author if you are uploading on behalf of someone else.

✓ Check that the author has their ORCID connected to their account.

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 you don’t have any group preferences, chose the repository main group Science For Life Laboratory. Each group receive 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 in order to suggest an appropriate group or regarding questions about the group assigned tothe item.

✓ Consult with the submitter if you have doubts about the appropriate group belonging. If the item belongs to a group project, the item should have the same group belonging as the project.

Please note: 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.

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.

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.

✓ Check if the uploaded item is labeled with the correct item type. When item type is presentation, poster or a preprint, take extra notice in making sure the submitter has permission to upload all that is included in the item, for example figures.

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. Units submitting an item are encouraged to include the name of the unit 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 and broadly applicable language.

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.

✓ Check if the keywords appear to be spelled correctly. Consider contacting the submitter if you have doubts about the spelling.

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 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 DOI to this software.

If the item is connected to an article, the abstract of the article could be included in the description.

Specific things to consider depending on the item type:

Dataset

In the description it should be clear how the data were obtained and what data each file contains. State who generated or collected the data and, if possible, specify the date this was done. Specify whether the data is raw or processed. In case of processed data, describe how it has been processed.

✓ Check that the description is somewhat sufficient for reusability of the item.

Funding

This is a non-mandatory field that can be used to add funding information related to your data or other 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.

Resource title and Resource DOI

These are non-mandatory fields that should be used to reference the publication connected to the item. The title and the DOI of the connected article should be stated in respective fields.

When the item is published, a title and hyperlink to the publication will appear in a box on the right-hand side of the public page for the item. This requires that both fields are filled out.

✓ Check that nothing more than the title of the connected article is stated and check that the resource DOI matches the title.

References

This is a non-mandatory field where references besides the reference to the article directly connected to the item could be listed. However, when adding a reference it is preferable to write an explanation for the reference, which is not possible in this field. Therefore references can be added, along with an explanation, in the field “Description”.

Below are some examples of references that can be added:

If the item was presented at a conference, please add a URL of the conference.

If discipline-specific vocabularies/ontologies/thesauri are used, please include an external source in which these are documented. The documentation should preferably be accessible for anyone. This will increase both the interoperability and reusability of the item.

A reference to the software needed to open the file (as well as appropriate version) can increase the reusability of the item.

✓ Check that all references are valid URL’s.

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. If access to the item is restricted, the Restricted Access licence should be chosen.

Available licences:

CC0
CC BY 4.0
CC BY-NC-ND 4.0
MIT
GPL
GPL 2.0 +
GPL 3.0 +
Apache 2.0
Restricted Access

✓ If it is a metadata record only, check that the licence is Restricted Access.

Publisher

This is a mandatory field where the submitter can state a publisher. The publisher can be, for instance, the university, the institute or the unit with which the submitter is affiliated. In general the publisher is the home organisation of the submitter and not the data owner.

✓ Check that the stated publisher is the home organisation of the submitter.

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

This is a non-mandatory field where the submitter can state an email address to which any access requests for the files should be sent. This is useful when the item has restricted access, for whatever reason. If you are using the built in request access functionality this field does not need to be filled out.

✓ If possible, check that the email address stated is a functioning email address.

✓ Check if the buit in request access functionality is being used. If so, this field should not be filled out.

Give feedback to the submitter

After the reviewer has checked the item and its metadata, they will be given three options.

Approve and publish
Decline and return
Comment

Approve and publish

See “Publish” below.

Decline and return

This option is relevant when the item, at least in its current state, is unsuitable for publication on the repository. This includes items for which no response to reviewers comments has been received from the submitter after five weeks. The submitter will be notified of this change by email. Reviewers should always include a comment detailing why the item is declined and returned.

Comment

This option is relevant when there are more substantial ‘errors’ in the item/metadata that needs to be edited by the submitter. 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.

Publish

The option Approve and publish is relevant when the item can be published as it is or when you only detect small ‘errors’ in the metadata that can be edited directly by the reviewer without consulting the submitter. If there is mandatory metadata missing or if you simply want to change some of the metadata, please use the Save button from the Edit item tab before approving. If you do not save the changes, you will approve the previous version.

When the reviewer is happy with both the item and its metadata the reviewer should choose the option 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.