Yes, figshare supports version control of all publicly available data. Any privately stored data can also be altered or deleted as you wish.
If you have accidentally published data which needs to be taken down, please see I've accidentally set my data to public, what should I do?
For a step-by-step guide on how to edit public and private items or delete private items please click here.
What is a new version?
Figshare supports versioning for both items and collections. Because projects are a continuous piece of work with a start date and finish date they are not candidates for versioning.
There are a couple of changes that would trigger versioning. These rules are a bit different between items and collections.
Provided it is a public figshare item, the following actions will trigger versioning when saving publicly:
- Modifying the title
- Add/edit/remove author/s
- Adding new files
- Removing files
- Replacing files
- Removing confidentiality from files
- Removing the metadata only flag and uploading files
- Replacing the link associated to a linked item
Provided it is a public figshare collection, the following actions will trigger versioning,when saving publicly:
- Modifying the title
- Adding new items
- Removing items
- Replacing items
- Upgrading the item’s version linked to the collection
These actions can be done from the website, the API or any submission method used by the user.
The same rules apply to individual figshare accounts and to institutional accounts or publisher accounts.
For the publisher accounts, figshare is able to remove the automatic versioning process and maintain only one public version.
Versions are listed and accessible in the drop down menu under the item title, each is timestamped.
What happens to the other changes except from the ones that trigger a new version?
Figshare allows users to perform any modification on public items.
Users can modify: description, authors, categories, keywords, licence, references, funding information and any defined custom metadata.
Upon choosing to publish the modifications, the user can see if he will generate a new version or only publish the changes. This is only visible if using the website, of course.
If the changes do not generate a new version, meaning they are performed on any other metadata field except the ones documented above, then they will be applied only to the latest public version.
If you already have an item with 3 versions and choose to change the title of the item, saving this change publicly will generate version 4.
If you only add a co-author, then you will affect only version 3. Versions 1 and 2 will continue to have the old set of co-authors.
If you have a collection with 2 versions and add one more file, then you will generate version 3 if you publish the changes.
If you have the same collection with 2 versions but you only add a new category to it, then this change will be reflected only on version 2. Version one will continue to have the old category set.
As a rule of thumb, old history versions cannot be modified by any means from website, API or other submission methods.
How are versions connected to DOI’s?
Every figshare item or collection version has a DOI. This exclude cases when publishers provide their own DOI for the data, in which case, they are responsible for assuring DOI correctness.
Every figshare item or collection has a base DOI. This DOI can be found by removing the version suffix from the DOI presented under Cite.
The base DOI always points to the latest public version.
For example, the base DOI of the item in the image above is: https://doi.org/10.6084/m9.figshare.2066037 and it will point to the latest version, which at the moment is 16.
Each of the versions have their own DOI and can be cited independently. The version DOI is created from the base DOI by adding the v<x> suffix, where x is the version number.
Do the versioning rules apply also to curation?
Yes, all the rules will apply if the items are going through a curation process. The only difference is that new versions or updates to existing versions are created only when the request is approved.
Users do not have a means to directly modify public items.