Page History

...

Important warnings - read before enabling

Enabling Item Level Versioning

...

Identifier Service Override

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.

Image Added

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, 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 with the example above, the first version of an Item gets the Handle 10673/100, the second version 10673/100.2, the third version 10673/100.3 and so on. This strategy has the downside that there is no handle always pointing to the newest version. But each version gets an identifier that can be use to cite exactly that version. If page numbers change in newer editions, the old citations stay valid. This strategy makes sense, especially if you present the version history to all users. In the image below you see a version history using this strategy.

Image Added

In DSpace 4 and 5, only the strategy using canonical handles (one handle that always points to the newest version) was implemented. In DSpace 6 the strategy of creating a new handle for each version was implemented and became the default. The strategy using the canonical handle still exists in DSpace but you have to enable VersionedHandleIdentifierWithCanonicalHandles in the file [dspace]/config/spring/api/identifier-serice.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 DOIs, you have to enable DOIs, use DataCite as the registration agency, and enable VersionedDOIIdentifierProvider in the named configuration file.

You can configure which persistent identifiers should be used by editing You can override the default behaviour of the Identifier Service using following XML configuration file, deployed under your dspace installation directory:

...

No changes to this file are required to enable Versioning. This file is currently only relevant if you aim to develop your own implementation of versioningwant to keep the identifier strategy from DSpace 4 and 5 or if you want to enable DOIs or even versioned DOIs.

Version History Visibility

...

versioning.item.history.view.admin=false

Allowing submitters to version their items (JSPUI only)

With DSpace 6.0 it became possible to allow submitters to create new versions of their own items. This currently works in JSPUI only and is switched off by default to keep the same behavior as XMLUI. 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.

Identified Challenges & Known Issues in DSpace 4.0

...