Page History
...
Important warnings - read before enabling
Warning | ||
---|---|---|
| ||
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 DS-1382. |
...
Warning | ||
---|---|---|
| ||
With version 6 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 |
...
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 builded 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 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 with 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/100.3 and so on. This strategy has the downside that there is no handle always pointing always to the newest version. But each version gets an identifier that can be use to cite exactly this that version. If page numbers changes 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.
In DSpace 4 and 5, only the strategy using canoical canonical handles (one handle that always points to the newest version) were was implemented. In DSpace 6 the strategy of creating a new handle for each version was implemented . With DSpace 6 this new strategy become and became the default. The strategy using the canonical handle still exists in DSpace but you have to change the configuration if you want to use it. 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 following XML configuration file, deployed under your dspace installation directory:
...
Code Block |
---|
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
...