SciLifeLab Data Repository Submission Guidelines

1. Through My data where you can drag and drop files of up to 5GB (default limit). To upload a folder of files, create a zip file of the folder and upload that file. This will perserve the file structure within the folder.
2. Using the FTP uploader or the Figshare API, especially when working with large file/s – most web browsers can only cope with single file uploads of up to 5 GB. For more on uploading using the FTP uploader see here. For documentation on using Figshare API, see here. For a quick start, see our GitHub repository with example scripts on interacting with the SciLifeLab Data Repository using API. Note that you should use the same base URL as for Figshare in general; based on the personal token that you generate in the SciLifeLab Data Repository, your item will be published in our repository.

A user’s quota can be updated if the user requests it. Administrators cannot modify quota directly for a user – they can only approve or reject the user’s request. To request more quota, the user needs to go in my data and request more from above the item table.

Readme and Manifest files

When publishing an item on the SciLifeLab Data Repository, please include both a README file and a manifest file with the item. Please note that this is not possible for a metadata record as it is not possible to upload files to a metadata record. However, it is always encouraged to keep a README and a manifest file with the data described by a metadata record. Adding a README and a manifest file will improve accessibility for those downloading the item. The README file should preferably contain the same metadata as that of the metadata form, including the DOI to the item. The manifest file should contain a list of every file included in the item. When uploading a file to the SciLifeLab Data Repository, a checksum for the file is automatically generated. Click on Preview item in the metadata form to view the files checksum. 

Metadata

When uploading an item you will be asked to fill in a metadata form. The metadata form includes both mandatory and non-mandatory fields. 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. 

Short SciLifeLab Data Repository tutorial, briefly presenting the procedure of adding a metadata only record to the repository.

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.  

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. 

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

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 SciLifeLab research group, platform or unit where applicable. Each created 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 to the item. See all currently public groups here.

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.

When uploading a presentation, poster or a preprint, take extra notice in making sure that you have 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, 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. 

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. 

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.

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.

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. 

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-SA 4.0
• CC BY-NC-ND 4.0
• MIT
• GPL 
• GPL 2.0 + 
• GPL 3.0 + 
• Apache 2.0
• Restricted Access

Publisher

This is a mandatory field where the submitter should 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. 

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. 

How to conditionally upload data

There are a number of reasons why you may want to conditionally upload your files, for example, you might want to restrict access until a publication is accepted or ensure that only certain users can access the item whilst it is under embargo. Multiple solutions exist to accommodate user requirements related to conditionally uploading an item/data. Please see the below table for advice on which solution would be most suitable for your needs.

Reason to conditionally upload data	Which section to look to for advice
Files may include ethically or commercially sensitive data	See ”Metadata record” section
Data/item can not be made available before a given date/indefinitely	See ”Embargo and restricted publishing” section
There is a need to enable some users/groups to access your item during the embargo period	See ”Embargo and restricted publishing” section
The data/files involved in the item are stored elsewhere, but you want to link it to this repository in order to get a DOI	See ”Linked file” section
You want to reserve a DOI for the data that you will include in a publication	See ”Reserve DOI” section
You want to make the data accessible only to reviewers while your manuscript is under review for publication	See ”Sharing private data” section

Metadata record

To create a metadata record, tick the metadata record only box at the top of the screen and enter a reason for this choice. This option will only appear if you haven’t uploaded a file to the item. When creating a metadata record we recommend to choose the license Restricted access and to add an email to the metadata field “access request email”.

Embargo and Restricted publishing

To use this functionality, select the Apply Embargo and restricted Access button in the metadata form. You can select a time period for the embargo or, select ‘permanent embargo’, where restrictions to the underlying data will apply. It is not necessary to apply the embargo to the entire item. Indeed, you can choose whether the embargo applies only to the files or to the entire content (files and metadata). You can then choose who can access the embargoed content (i.e. before the embargo period expires). By choosing “Nobody”, you ensure that nobody will have access to the embargoed content until the embargo period expires.  Choosing “Custom” instead enables you to select whether access should be restricted  to all users of the SciLifeLab Data Repository when they are logged in.

The item owner can also change the title of the embargo to describe the type of embargo applied (the standard text is ‘File(s) under embargo’) and can optionally add a reason as to why this item is under an embargo. 

Request access

It is now possible to allow users to request access to your embargoed files. Note though that this functionality is not available for metadata only records. To enable the functionality, tick the Allow anybody to request access to the embargoed files box. You can include additional information, such as a Data access statement, for anyone requesting access to the files. When this functionality is enabled, a button with the text Request access to files will appear on your published item. Anyone looking to request access needs to be a user of a Figshare instance. When users click on this button, they will see your Data access statement and can choose to send an access request. If a user requests access to your restricted files through this feature, you and your institutional administrators will receive an email request to grant access. There is currently no way to share restricted access files with a user in the interface, this has to be done using an external service.

Linked file

Click the Link File button at the top of the screen and copy the link in the box. This option only appears if you haven’t uploaded a file to the item.  

Reserve DOI 

Click on the Reserve Digital Object Identifier button in the metadata form to reserve a DOI for your item. This DOI becomes active when the item is published and can be used to cite your data in publications.  

Sharing private data

Click on the Generate private link button in the metadata form to create a link that you can share. If desired, this link can be disconnected in the future. To find the private link for an item in a project, click on the item and then Share. However, this is only possible after the item owner has generated the private link. Please note that the private link should not be used to cite your data in publications. 

Projects

Projects are collaborative spaces used for ongoing work. You can upload data that is in progress and have collaborators make comments. You can also collaborate with people outside SciLifeLab by inviting them to your project.

Please note that the project owner and members cannot edit another uploader’s items. Items must be downloaded, edited, and re-uploaded to the project. To create a project, go to My Data, select the Projects tab and click on the +Create a new project button.

Project members can either be collaborators or viewers. Invite members with existing accounts (institutional or figshare.com) by using the search function. The invited members will see their invite under the Activity page. When they accepted the invitation the project will appear under their Project page. Invite members without an account by clicking on the invite new users link. The invited members will receive an email including a link to create a figshare.com account. Outside of the scope of a project users with figshare.com accounts will publish their items on figshare.com and their future work won’t be associated with SciLifeLab. 

There are two different types of projects: individual projects and group projects. The person creating the project will be the owner of the project regardless of project type chosen.

Individual Projects	Group Projects
Everyone uses their own quota and account storage.	Submitters’ quota will not be used, storage allocation comes directly from the project.
People take their work with them if they leave the project.	All work is stored on institutional storage and remains within the project space if people leave.
Items are created using the metadata schema of the submitter.	Contributors must adopt the metadata schema of the project owner.
Items appear in the group chosen in the review process.	Items appear in the group chosen in the review process. It is recommended for this to be the same group as chosen for the project.
Items published by users from outside the organisation don’t have to go through review.	Items published by users from outside the organisation have to go through review.

In order to add a new item to a project, select Add a new item, which takes you to the metadata form. Once you’ve saved the item, it will appear in the home page of the project. If you wish to add an item from My data to an existing or newly created project, you can do this by selecting the item/s, clicking Actions (located just above) and selecting the desired project destination.

Collections

Publish items

Before you send your item to be published, please make sure everything you have submitted is accurate – once published, it will be permanently available

After ticking Publish, you’ll be prompted to double-check both the licence that you’ve assigned to the item and the terms of use. Once you have confirmed your selections, your item will then be sent for review by SciLifeLab’s institutional reviewers. If you’re submitting a brand new item, the reviewers are likely to send you an email detailing changes that you should make in order to maximize the reusability of the item. Once you have made these changes, and confirmed this with the reviewers, the item can then be made public. If the reviewers do not receive a response within five weeks, then the item will be sent back to you. The status of the item in your account will then show as ‘declined’, rather than ‘under review’. This does not mean that your item has been ‘rejected’ in any way. Rather, it reflects that the reviewers will not actively continue reviewing your item at this time. You are very welcome to send the item for review again whenever you are ready. More information about the reviewing process can be found in the Data Reviewing Guidelines.

Edit items

You can go back and edit items after you’ve made them publicly available. To edit an item, click on the pencil that appears to the right of your item when hovering over it in My Data.  You can also batch edit items that have already been published: in My Data, select the items to be updated, click on Actions at the top of the page, and select Edit in batch. Once you’ve selected the items to be edited in bulk, select the metadata fields to edit.

When editing a published item the item will be sent for a new review. When editing an embargoed record, amending or removing the embargo will also send the item back for review. To expedite this review, please send a message to datacentre@scilifelab.se and explain which changes that were made to the item. When adding, removing or replacing files, remeber to also update the manifest file to reflect the new state of the item.

Some changes may trigger a new version of the item. See here to find out which amendments will generate a new version. When a new version is generated, the previous versions will still be available. Each version will have its own DOI, where the version number is added as a suffix to the base DOI. See this item as an example. The base DOI will always point to the latest public version on the item. 

Delete items

Click on the Delete item button in the metadata form to delete a private item. 

Published items are considered to be published permanently and can only be deleted in special cases. If you wish to delete a published item please contact Data Centre at datacentre@scilifelab.se.

For further questions, please contact datacentre@scilifelab.se.