Versions Compared

Old Version 4

changes.mady.by.user Bram Luyten (Atmire)

Saved on

compared with

New Version 5

changes.mady.by.user Tim Donohue

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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.

Enabling Item Level Versioning

By default, Item Level Versioning is disabled in DSpace 3.0.  This feature is currently only supported in the XMLUI.

If you wish to enable this feature, you just have to uncomment the "Versioning" aspect in your [dspace]/config/xmlui.xconf file (and restart your servlet container):

Code Block
<!-- =====================
     Item Level Versioning
     ===================== -->
<!-- To enable Item Level Versioning features, uncomment this aspect. -->
<aspect name="Versioning Aspect" path="resource://aspects/Versioning/" />
Warning
titleAIP Backup & Restore functionality only works with the latest version of Items

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.

 

Requirements

  1. What is Versionable
    1. Versioning is at the level of an Individual Item
    2. Should preserve the current state of metadata, bitstreams and resource policies attached to the item.
  2. Access, Search and Discovery
    1. Only the most recent version of an item is available via the search interface
    2. Previous Versions of Items should continue to be visible, citable and accessible 
    3. The Previous Versions Bitstreams are retained. If something was once retrievable, it is always retrievable.
  3. Identifiers
    1. Each version of an Item is represented by a separate "versioned" identifier
    2. A base "versionhistory" Identifier points to the most recent version of the Item. 
    3. A revision identifier also exists that is unique to the specific version.
    4. When a new version of an Item is deposited, a new revision identifier will be created.
  4. Presentation
    1. On the item page, there is a link to view previous/subsequent versions.
    2. By examining the metadata or identifiers, it is possible to determine whether an item is the most recent version, the original version, or an intermediate version.
  5. Access Control and Rights
    1. Certain roles should be able to generate a new version of the item via submission.
    2. To submitters, collection manager, administrators will be given to option to create new version of an  item.
    3. Rights to access a specific Item should transmute as well to previous versions
    4. Rights to access a specific Bitstream should also transmute to previous versions.
  6. Data Integrity
    1. The relationships between versions should not be brittle and breakable by manipulating Item metadata records.
    2. The relationships between versions should be preserved and predictable in various Metadata Exports (OAI, Packagers, ItemExport)
    3. The relationships between versions should be maintained in SWORD, LNI and AIP packaging and be maintained in updates and restorations.

...