Page History

...

Higher Priority Requirements

1. What is Versionable
   1. Versioning is at the level of
   individual Items, User should be able to generate a new version of the item via submission, sword or LNI deposit.
2. Previous Versions of Items should continue to be visible, citable and accessible 
3. 1. an Individual Item
   2. Should preserve the current state of metadata, bitstreams and resource policies attached to the item.
4. Access, Search and Discovery
   1. Only the most recent version of an item is available via the search interface (possibly configurable)
   2. Previous Versions of Items should continue to be visible, citable and accessible 
   3. The Previous Versions Bitstreams
   Previous versions of bitstreams
   1. are retained. If something was once retrievable, it is always retrievable.
5. Identifiers A base "versionhistory" Identifier points to the most recent version
   1. Each version of an Item is represented by a separate "versioned" identifier (Handle or DOI)
6. The relationships between versions should be visible in various Metadata Exports (OAI, Packagers, ItemExport)
7. Expose Versioning detail in DSpace API and Services (I.E. OAI, Bagit, Etc.)
8. The relationships between versions should not be brittle and breakable by manipulating Item metadata records.
9. 1. A base "versionhistory" Identifier points to the most recent version of the Item. 
   2. A revision identifier also exists that is unique to the specific version.
   3. When a new version of an Item is deposited, a new revision identifier will be created.
10. When a new version of an Item is deposited the "versionhistory" identifier will resolve to the new version.
11. Each version of the item includes metadata about who created the version and the date/time. (it is essentially a full copy of the item, with modifications)
12. Presentation
    1. On the item page, there is a link to view previous/subsequent versions.
    2. Each version of the item should include additional provenance details about who created the version, when and why.
    3. 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.
13. Access Control and Rights
    1. Certain roles should be able to generate a new version of the item via submission, sword or LNI deposit.
    2. Submitters: Creation of a new version is initiated by the
    author
    1. original submitter. On the "submissions" page,
    users
    1. submitter should see all of their archived submissions. 
    Each archived submission should
    1. Collection Manager, Administrators: should have a button to submit a new version of a
    Item accessible by the Submitter or the Collection Manager, AdministratorsOnly the most recent version of an item is available via the search interface (possibly configurable)
    1. Item accessible in the Edit Item administrative interface.
    2. Rights to access a specific Item should transmute as well to previous versions
    3. Rights to access a specific Bitstream should also transmute to previous versions.
14. 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.

 Lower Priority Requirements

...