Versioning is a new functionality to build the history of an item. Users will have the opportunity to create new version of an existing item any time the will make a change.
Item level versioning was not fully supported in DSpace 7.0 (you were only able to view existing versions). It was restored in DSpace 7.1. See DSpace Release 7.0 Status |
Configurable Entities are supported in Item Level Versioning support starting from version 7.3. More details about the configuration specific to Configurable Entities can be found on that page. |
If you are using the AIP Backup and Restore functionality to backup / restore / migrate DSpace Content, you must be aware that the "Item Level Versioning" feature is not yet compatible with AIP Backup & Restore. Using them together may result in accidental data loss. Currently the AIPs that DSpace generates only store the latest version of an Item. Therefore, past versions of Items will always be lost when you perform a restore / replace using AIP tools. See https://github.com/DSpace/DSpace/issues/4751. |
Starting with 6.0, the way DSpace crates Handles for versioned Items was changed. If you want to keep the old behavior of DSpace 4 and 5 you have to enable the |
By default, Item Level Versioning is enabled in DSpace 7. You may choose to disable it by updating this configuration in your local.cfg:
versioning.enabled = false |
Additionally, you will need to make the following changes to disable all versioning-related features:
Switch to using the basic "HandleIdentifierProvider" in your [dspace]/config/spring/api/identifier-services.xml
. Make sure to comment out the "VersionedHandleIdentifierProvider" and replace it with this:
<!-- This HandleIdentiferProvider should be used when versioning is disabled --> <bean id="org.dspace.identifier.HandleIdentifierProvider" class="org.dspace.identifier.HandleIdentifierProvider" scope="singleton"> <property name="configurationService" ref="org.dspace.services.ConfigurationService"/> </bean> |
Remove the "versioning" consumer from the list of default Event Consumers in either your dspace.cfg or local.cfg. Look for this configuration:
# Remove the "versioning" entry in this list # (NOTE: Your list of consumers may be different based on the features you've enabled) #event.dispatcher.default.consumers = versioning, discovery, eperson # For example: event.dispatcher.default.consumers = discovery, eperson |
Once these changes are made, you will need to restart your servlet container (e.g. Tomcat) for the new settings to take effect.
The Item Level Versioning implementation builds on following requirements identified by the stakeholders who supported this contribution: Initial Requirements Analysis
From the user interface, DSpace offers linear versioning. As opposed to hierarchical versioning, linear version has following properties:
Administrators, collection/community administrators and eventually the original submitter can create new versions of an item from the Item View page. By default the original submitter is not allowed to create new version but the permission can be granted with the following property
versioning.submitterCanCreateNewVersion=false |
After the submission steps and the execution of subsequent workflow steps, the new version becomes available in the repository.
Versions can be also managed via the edit item page, in the dedicated versions tab
An overview of the version history, including links to older versions of an item, is available at the bottom of an Item View page. The repository administrator can decide whether the version history should be available to all users or restricted to administrators. By default, this information is available to all users. Information displayed includes the version number, Submitter/Editor name (only if enabled), date, and summary/description. As necessary, you may change the visibility of this table or the "Editor" column using the "Version History Visibility" configurations below.
For every new Version a separate DSpace Item will be created that replicates the metadata, bundle and bitstream records. The bitstream records will point to the same file on the disk.
The Cleanup method has been modified to retain the file if another Bitstream record point to it (the dotted lines in the diagram represent a bitstream deleted in the new version), in other words the file will be deleted only if the Bitstream record processed is the only one to point to the file (count(INTERNAL_ID)=1).
You can override the default behaviour of the Versioning Service using following XML configuration file, deployed under your dspace installation directory:
[dspace_installation_dir]/config/spring/api/versioning-service.xml
In this file, you can specify which metadata fields are automatically "reset" (i.e. cleared out) during the creation of a new item version. By default, all metadata values (and bitstreams) are copied over to the newly created version, with the exception of dc.date.accessioned and dc.description.provenance. You may specify additional metadata fields to reset by adding them to the "ignoredMetadataFields" property in the "versioning-service.xml" file:
<!-- Default Item Versioning Provider, defines behavior for replicating Item, Metadata, Budles and Bitstreams. Autowired at this time. --> <bean class="org.dspace.versioning.DefaultItemVersionProvider"> <property name="ignoredMetadataFields"> <set> <value>dc.date.accessioned</value> <value>dc.description.provenance</value> </set> </property> </bean> |
Persistent Identifiers are used to address Items within DSpace. The handle system is deeply integrated within DSpace, but since version 4 DSpace can also mint DOIs. DSpace 4 and 5 supported one type of versioned handle: The initial version of an Item got a handle, e.g. 10673/100. This handle was called the canonical one. When a newer version was created, the canonical handle was moved to identify the newest version. The previously newest version got a new handle build out of the canonical handle extended by a dot and the version number. In the image below you see a version history of an item using this handle strategy.
The canonical handle will always point to the newest version of an Item. This makes sense if you hide the version history. Normal users won't be able to find older versions and will always see just the newest one. Please keep in mind, that older versions can be accessed by "guessing" the versioned Handle if you do not remove the read policies manually. The downside of this identifier strategy is that there is no permanent handle to cite the currently newest version, as it will get a new Handle when a newer version is created.
With DSpace 6 versioned DOIs (using DataCite as DOI registration agency) were added and the default versioned Handle strategy was changed. Starting with DSpace 6 the VersionedHandleIdentifierProvider
creates a handle for the first version of an item. Every newer version gets the same handle extended by a dot and the version number. To stay by the example from above, the first version of an Item gets the Handle 10673/100, the second version 10673/100.2, the third version 10673.3 and so on. This strategy has the downside that there is no handle pointing always to the newest version. But each version gets an identifier that can be use to cite exactly this version. If page numbers changes in newer editions the old citations stay valid.
In DSpace 4 and 5 only the strategy using canonical handles (one handle that always points to the newest version) were implemented. In DSpace 6 the strategy of creating a new handle for each version was implemented. With DSpace 6 this new strategy become the default. The strategy using canonical handle still exists in DSpace but you have to enable the VersionedHandleIdentifierWithCanonicalHandles
in the file [dspace]/config/spring/api/identifier-service.xml
. With DSpace 6 versioned DOIs were introduced using the strategy that every new version gets a new DOI (extended by a dot and the version numbers for versions >= 2). To use versioned Handle you have to enable DOIs, you have to use DataCite as registration agency and you have to enable the VersionedDOIIdentifierProvider
in the named configuration file.
You can configure which persistent identifiers should be used by editing following XML configuration file, deployed under your dspace installation directory:
[dspace_installation_dir]/config/spring/api/identifier-service.xml
No changes to this file are required to enable Versioning. This file is currently only relevant if you want to keep the identifier strategy from DSpace 4 and 5 or if you want to enable DOIs or even versioned DOIs.
By default, all users will be able to see the version history. To ensure that only administrators can see the Version History, enable versioning.item.history.view.admin
in the [dspace]/config/modules/versioning.cfg
OR in your local.cfg
file.
# Setting this to "true" will hide the entire "Version History" table from # all users *except* Administrators versioning.item.history.view.admin=false |
In either the [dspace]/config/modules/versioning.cfg
configuration file or your local.cfg
, you can customize the configuration option versioning.item.history.include.submitter
. By default this is set to false, which means that information about the submitter is only viewable by administrators. If you want to expose the submitters information to everyone (which be useful if all submitters uses generic institutional email addresses, but may conflict with local privacy laws if personal details are included) you can set this configuration property to true.
# This property controls whether the name of the submitter/editor # of a version should be included in the version history of an item. # Set to "true" to show the submitter to all users who have access to the table. # Set to "false" to hide the submitter information from everyone except Administrators versioning.item.history.include.submitter=false |
With DSpace 6.0 it became possible to allow submitters to create new versions of their own items. The new versions are going through the normal workflow process if the collection is configured this way. To allow submitters to create new versions of Item they originally submitted, you have to change the configuration property versioning.submitterCanCreateNewVersion
and set it to true
. It is part of the configuration file [dspace
]/config/modules/versioning.cfg
but can be overridden in your local.cfg
too.
Item Level Versioning has a substantial conceptual impact on many DSpace features. Therefore it has been accepted into DSpace as an optional feature. Following challenges have been identified in the current implementation. As an early adopter of the Item Level Versioning feature, your input is greatly appreciated on any of these.
Lifting an embargo currently does not interact with Item Level Versioning. Additional implementation would be required to ensure that lifting an embargo actually creates a new version of the item.
Both on the level of pageviews and downloads, different versions of an item are treated as different items. As a result, an end user will have the impression that the stats are being "reset" once a new version is installed, because the previous downloads and pageviews are allocated to the previous version.
One possible solution would be to present an end user with aggregated statistics across all viewers, and give administrators the possibility to view statistics per version.