SciLifeLab Data Repository Reviewing Guidelines

Reviewing is the act of approving or rejecting an submitted item, with feedback, before it becomes publicly available.

Reviewers

There are two different types of reviewer, institutional and group reviewer. An institutional reviewer can approve and manage revision requests from every group in the SciLifeLab institution. Whereas a group reviewer only can manage requests coming within their group and subgroups below their managed groups.

Institutional reviewer

This role is available only in the Configure institution page. Institutional reviewers can assign and unassign requests from everyone.They can also edit all the metadata for the items sent in for review and assigned to them. Institutional reviewers can add comments and send emails to submitting authors, for any of the pending/open requests visible to them.

As an institutional reviewer you can turn on reviewing in the Administration page by selecting the group you want to turn on reviewing for (groups inherit reviewing settings, so if you turn it on at the top level, all subgroups will have reviewing turned on, as well), selecting Configure, and scrolling down to Administration. There, you will have the option to turn on reviewing.

Group reviewer

This role is available only in the Configure group page, displayed as Reviewer in the role drop down. Group reviewers can only assign requests to themselves. They can also edit all the metadata for the items sent in for review and assigned to themselves. Group reviewers can add comments and send emails to submitting authors for any of the pending/open requests visible to them.

Notification of the reviewers 

When an end user chooses to publish an item on the SciLifeLab Data Repository, an email is automatically sent to every reviewer stated as reviewers for the group the item is published in. 

All reviewing requests can be found in the reviewing pool from the reviewer account. All reviewers set either at the group level or institution level will receive both email notifications and will also have them listed in the reviewing pool. If you would like to receive reviewing requests for every subgroup at your institution, you will need to add yourself as a reviewer to each subgroup or you can simply set yourself as an institutional reviewer. While you won’t be displayed as a reviewer on every Edit group page, you will be an implicit reviewer there and you will receive all the requests.

If the user creates the item in My data, then the review request will go to the group the user is assigned to. If the user creates the item in a group project, then the reviewing request is sent to that group. 

Please note: when creating items in projects, it is important to remember that reviewing is connected at group level, so depending on the group you select to link the project to might or might not have reviewing turned on.

View review requests

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. The number might be different from what you see when you enter the pool. By default, the pool shows all the requests even if they are assigned already, filtered by the group(s) you can review. If you know there are open review requests but you cannot see them, it means they must be assigned to groups that you cannot review.  

Assign a reviewer

To process an item through review, select the item and assign it to yourself as the reviewer. As an institutional reviewer, you can assign the request to yourself or to other reviewers that are assigned to the same group of the request. If you are a group reviewer, you can only assign the request to yourself.

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:Download

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 manifest file can be found here:Download

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. If the item is connected to an article, it may be appropriate for the item title to be the same as the title of the article or to include the article title in the item title. 

✓ In the case of the item being connected to an article, check if the title corresponds to the title of the article. If not, consult with the submitter to determine whether this was intentional.

Authors

This is a mandatory field where the submitter can add the authors of the item. Every author that has been involved in the creation of the item should be added here; adding all of the authors makes the item more findable. 

If the item is connected to an article the authors listed here could be the same as the authors of the article, but this is not always the case.  

✓  In the case of the item being connected to an article, check if the authors listed here seem reasonable in relation to the authors of the article. Consider contacting the submitter if you have doubts about the authors stated.

Categories

This is a mandatory field where a discipline category is chosen for the item. The list of categories is fixed and based on the Australian and New Zealand Standard Research Classification (ANZSRC) Fields of Research (FOR) codes. Choose all categories that apply for the item. The list of categories is not specific for the field of life science which sometimes can make it difficult to find a correct category. However, remember that the keywords can be used to increase specificity in those cases.  

Group(only for reviewers)

This is a mandatory field that is filled out by a reviewer. The purpose of this field is to connect the item with the correct research group or facility where applicable. The submitter can contact the data centre regarding questions about the group assigned to the item. 

✓ Choose the correct group for the item. If the item does not have a clear connection to one specific group, choose the highest group level, Science For Life Laboratory.  

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:

  • Figure. Figures are generally photos, graphs and static images that would be represented in traditional pdf publications.
  • 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.
  • 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.
  • 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.
  • Journal Contribution. Any type of content formally published in an academic journal, usually following a peer-review process.
  • 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.
  • 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.
  • 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.
  • Online Resource. Any type of resource available online.
  • 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.
  • 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.


✓ Check if the uploaded item is labelled 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. 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 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. For someone interested in the item it can be informative to know the purpose of the item, e.g. why was it generated/produced. If the item is connected to an article, the abstract of the article could be included in the description. 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. Add a URL or DOI to this software in the metadata field labelled References. In order to increase interoperability of the item the description should be written in a formal, accessible, shared and broadly applicable language for knowledge representation. 

Specific things to consider depending on the item type:

Dataset

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.  

✓ In the case of the item being connected to an article, check if the article abstract is included in the description.

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. 

Resource title

This is a non-mandatory field that should be used to reference the publication connected to the item. Only the title of the connected article should be included here.

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

✓ Check that nothing more than the title of the connected article is stated here.

Resource DOI

This is a non-mandatory field that should be used to reference a publication that is connected to the item. If the item is connected to an article, the DOI of that article should be included here.

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

✓ Check if the resource DOI matches the stated resource title.

References 

This is a non-mandatory field where all references besides the reference to the article directly connected to the item should be listed. For all references added here, an explanation of it should be included 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.  

License

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 or the publisher. 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 facility with which the submitter is affiliated. In general the publisher is the home organisation of the submitter and not the data owner.

✓ Check that a publisher has been stated correctly. 

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 possible, check that the email address stated is a functioning email address.

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 is unsuitable for publication on the repository. The submitter will be notified of this by email. The reviewer should include a comment specifying 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.

This website uses cookies to improve your experience. We'll assume you're ok with this, but you can opt-out if you wish. Ok!Read More
Privacy & Cookies Policy

Privacy Overview

This website uses cookies to improve your experience while you navigate through the website. Out of these cookies, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may have an effect on your browsing experience.
Necessary
Always Enabled

Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.

Non-necessary

Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.

SAVE & ACCEPT