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:
Provided it is a public figshare collection, the following actions will trigger versioning, when saving publicly:
These actions can be done from the website, the API or any submission method used by the user. Of course, the user can modify the title for example but also another field that would not trigger a new version. In this situation since the title has been changed, we would generate a new version that would have both the new title and the other metadata changed.
The same rules apply to individual Figshare accounts and to institutional accounts or publisher accounts.
For accounts owned by publishers, 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 when I change other metadata except for the ones that trigger new versions?
Figshare allows users to perform any modification on public items.
Users can modify: description, categories, keywords, licence, item type, references, funding information and any defined custom metadata.
Upon choosing to publish the modifications, the user can see if they 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 new Category then you will affect only Version 3. Versions 1 and 2 will continue to have the old set of Categories.
If you have a collection with 2 versions and add one more item, 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.
If in the same update you modify the title of an item and also add a new keyword, then you will generate a new version that will have the new keyword. The old version would not have this keyword.
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.
Share this article: