...

• Mark Diggory - @mire
• Holly Miller - MBL
• Diane Rielinger - MBL
• Lisa Raymond - WHOI 
• Ryan Scherle - NESCent / Dryad

Administration

1. Current Code Locations
   1. https://dryad.googlecode.com/svn/trunk/dryad/dspace/modules/

Business Requirements / Goals

The history of an item should be available, and it should be possible to cite a particular version of the item.

Higher Priority Requirements

...

User Scenarios

General user actions that would generate a new

...

Version of a new Item and their overal impact on creation of a new DSpace item.

1. Release of a new scientific dataset with additional data
2. Release of a corrected scientific dataset with altered data
3. Release of a revised or corrected journal article, technical report, ...

Higher Priority Requirements

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. Previous versions of bitstreams are retained. If something was once retrievable, it is always retrievable.
4. Each version of an Item is represented by a separate "versioned" identifier (Handle or DOI)
5. The relationships between versions should be visible in various Metadata Exports (OAI, Packagers, ItemExport)
6. Expose Versioning detail in DSpace API and Services (I.E. OAI, Bagit, Etc.)
7. The relationships between versions should not be brittle and breakable by manipulating Item metadata records.
8. A base "versionhistory" Identifier points to the most recent version of the Item. 
9. A revision identifier also exists that is unique to the specific version.
10. When a new version of an Item is deposited, a new revision identifier will be created.
11. When a new version of an Item is deposited the "versionhistory" identifier will resolve to the new version.
12. 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)
13. On the item page, there is a link to view previous/subsequent versions.
14. By examining the metadata, it is possible to determine whether an item is the most recent version, the original version, or an intermediate version.
15. Creation of a new version is initiated by the author. On the "submissions" page, users should see all of their archived submissions. 
16. Each archived submission should have a button to submit a new version of a Item accessible by the Submitter or the Collection Manager, Administrators
17. Only the most recent version of an item is available via the search interface (possibly configurable)

 Lower Priority Requirements

1. All metadata and content changes within a "Version" should be logged in an audit trail

Technical Requirements and Existing Implementation

Administration

1. Current Code Locations
   1. https://dryad.googlecode.com/svn/trunk/dryad/dspace/modules/

Services that are effected by user scenarios

• Local User Submissions and Curator Reviews.
• SWORD and LNI Deposit interfaces
• Local ItemImport and Export Command-line services.
• External Harvesters (OAI and DSpace)
• Academic Search Engines and Catalogs.

Work Areas for Implementation of Version History

1. Database Modifications
2. Data Access Objects and Domain Model definition
3. Enhancing DSpace XMLUI Item Adapter to expose Version Details on Items
4. Item User Interface Changes to support Versioning
   1. Details that should be presented in User Interface
   2. Actions that should be possible on existing versions (compare, revert, delete, withdraw)
   3. Actions that should be possible to generate a new version (submission, deposit, import)
   4. Roles for which new versions should be possible (submitter, author, curator)
5. Local User Submissions and Curator Reviews.
6. Services that are effected by user scenarios
   1. SWORD v1 and v2 Version creation on Update
   2. LNI Version on Update
   3. Local ItemImport and Export Command-line services.
   4. Metadata Export and Import
   5. External Harvesters (OAI and DSpace)
7. Further Requirements to Consider
   1. Deleting an Item from the Repository
   2. Moving and Item Between Collections
   3. Mapping an Item to another collection

Dryad Solution for Versioning

Services to support Versioning and Alternative Identifiers.  DSpace Item Versioning will be encapsulated as an Extensible Service that may be reimplemented by the local repository maintainers to produce alternate versioning behaviors and Identifier Schemes. Versioning Services layer on top of IdentifierServices dedicated to Encoding, Resolution, Minting and Registration of Identifiers for specific DSpace Items and Bitstreams.  It is through this highly extensible layering of functionality where local developers can alter the versioning behavior and introduce their own local enhancements.  The DSpace Service Manager, based on the Spring Framework, provides the key leverage for this flexibility.

Versioning Service

The Versioning Service will be responsible for the replication of one or more Items when a new version is requested.  The new version will not yet be preserved in the Repository, it will be preserved when the databases transactional window is completed, thus when errors arise in the versioning process, the database will be properly kept in its original state and the application will alert that an exception has occurred that is in need of correction.

The Versioning Service will rely on a generica IdentifierService that is described below for minting and registering any identifiers that are required to track the revision history of the Items.

Identifier Service

The Identifier Service maintains an extensible set of IdentifierProvider services that are responsible for two important activities in Identifier management:

1. Resolution: IdentifierService act in a manner similar to the exisitng HandleManager in DSpace, allowing for resolution of DSpace Items from provided identifiers.
2. Minting: Minting is the act of reserving and returning an identifier that may be used with a specific DSpaceObject.
3. Registering: Registering is the act of recording the existence of a minted identifier with an external persistent resolver service, these services may reside ont he local machine (HandleManager) or exist as external services (PURL or DEZID DOI registrations services)

The IdentifierProviders are also responsible for altering any existing DSpace metadata fields that need to be altered on the new and previous items to record the relationship between Item Versions.

Image Added

DSpace Data Model and Versioning

Past Architectural Review Group work on the DSpace Data Model and versioning focused its research and recommendations on replicating the entire DSpace Item contents when a new DSpace Item was created in DSpace. This means that all item metdata and content would be replicated. This was done to ease the complexity of managing references across individual Items to the content and metadata that would be considered the same across those versions.

In the GSoC project to address versioning, we made an effort to optimize on the above situation and emplyed the following strategy for the production of a New version of a DSpace Item

DSpace Item Objects:

For every new Version a separate DSpace Item will be created that replicates the metadata and bundle records to allow multiple Items to share references to existing bitstreams that do not change across versions.

DSpace Bundle Objects:

For every new version of an Item, a Bundle will be created and the Bundle will link to all the preexisting bitstreams for the original Item. This means that Bitstreams may be associated with more than one Item by being linked by Bundle.

DSpace Bitstream Objects:

The versioning support in Dryad is based on replicating DSpace Item, MetadataValue and Bundle Records, creating an identical version of all Metadata and Bitstream relationships. The new version of the Item "conserves" Bitstream Contents by reusing references to the persisted Bitstreams across individual Item Revisions. 

The Bitstream deletion logic in DSpace is enhanced to support detecting if the Bitstream is no longer a member of any Item Revisions before being flagged as deleted. 

Image Added

Item View and Administrative Interfaces

Versioning edits to an Item

With a full feature versioning capability on Items, we may possibly be able to support restoration of Item Versions through an interface such as this WIKI page example interface. Image Added
Examples of Items with an additional Item Version Attached

Version 1 Image Added

Version 2 Image Added

Edit Item and Version Management

 Lower Priority Requirements

1. All metadata and content changes within a "Version" should be logged in an audit trail

Technical Requirements and Existing Implementation

Work Areas for Implementation of Version History

• Database Modifications
• Data Access Objects and Domain Model definition
• Enhancing DSpace XMLUI Item Adapter to expose Version Details on Items
• Item User Interface Changes to support Versioning
  • Details that should be presented in User Interface
  • Actions that should be possible on existing versions (compare, revert, delete, withdraw)
  • Actions that should be possible to generate a new version (submission, deposit, import)
  • Roles for which new versions should be possible (submitter, author, curator)

User Scenarios

General user actions that would generate a new Version of a new Item and their overal impact on creation of a new DSpace item.

1. Release of a new scientific dataset with additional data
2. Release of a corrected scientific dataset with altered data
3. Release of a revised or corrected journal article, technical report, ...

Services that are effected by user scenarios

• Local User Submissions and Curator Reviews.
• SWORD and LNI Deposit interfaces
• Local ItemImport and Export Command-line services.
• External Harvesters (OAI and DSpace)
• Academic Search Engines and Catalogs.

Metadata Mapping

Initial Requirements for Dryad anticipated exposure of versioning information as metadata fields,  shortly after the initial draft of an implementation proposal.  It was determined that it was critial that Referential Integrity be maintained when versioning DSpace Items.  Utilizing metadata fields was abandoned as an approach and a version history database table and Domain Model was introduced to support version histories.

versioning should mainta

General Versioning of DSpace Items

Generic Versioning of DSpace Items will involve the alteration of existing handles for those versions in DSpace. Versioning will utilize DCMI concepts for describing the relationships between Item Versions. This is not a commitment that versioning detail will exist in generic DSpace metadata records. But that it may be exposed as additional technical and descriptive metadata sections in simple OAI Dublin Core records and METS Manifests

While past recommendation are that identifiers that are assigned to items be opaque, we have two possible benefit from selecting a versioning scheme for the identifiers.

1. The original Item and the version currently being referred to are captured in the identifier.
1. Resolution of the most current version can be attained programmatically without having to navigate the version hierarchy

The goal behind this versioning approach is to capture the version of the Item while retaining its original version stream id. In the above case the DSpace Item Handle will be added the the Handle Manager and resolvable via CNRI.

• Reference to the most current version of the Item: http://hdl.handle.net/1234.5/1
• Reference to a specific version in the version history: http://hdl.handle.net/1234.5/1.1

Versioning of the Dryad Data Package and its Identifiers

Adopting the General Solution in dealing with Composite Dryad Data Packages with Data Files will employ the same approach, but with doi identifiers.

Versioning of the Items will utilize versioning capabilities that have been developed in the Dryad IdentiferServices.

Versioned Identifiers in DOI Service

Dyrad will expose semantic detail on the version of an Identifier by encoding it in the DOI. This DOI Service will be extensible and can be overridden by the repository maintainers to implement different identifier encoding schemes.

For Dryad:

<prefix>/<package-doi>.<version-id>/<datafile.id>.<version.id>

For Generic DSpace, both Handles and DOI support will be available:

<prefix>/<item-doi>.<version-id>
<prefix>/<item-handle>.<version-id>

Dryad DOI Version Adjustment Grid ( * Bold designates Version Change)

Generic DSapce DOI Version Adjustment Grid ( * Bold designates Version Change)

DSpace Data Model and Versioning

Past Architectural Review Group work on the DSpace Data Model and versioning focused on replicating the item contents when a new DSpace Item was created in DSpace This means that all item metdata and content would be replicated. This was done to ease the complexity of managing references across individual Items to the content and metadata that would be considered the same across those versions.

In the GSoC project to address versioning, we made an effort to optimize on the above situation and emplyed the following strategy for the production of a New version of a DSpace Item

DSpace Item Objects:

For every new Version a separate DSpace Item will be created that replicates the metadata and bundle records to allow multiple Items to share references to existing bitstreams that do not change across versions.

DSpace Bundle Objects:

For every new version of an Item, a Bundle will be created and the Bundle will link to all the preexisting bitstreams for the original Item. This means that Bitstreams may be associated with more than one Item by being linked by Bundle.

DSpace Bitstream Objects:

Image Removed

Business Model

DSpace Item Versioning will be encapsulated as an Extensible Service that may ne reimplemented by the local repository maintainers to produce alternate versioning behaviors and Identifier Schemes,

Image Removed

Versioning Service

The Versioning Service will be responsible for the replication of one or more Items when a new version is requested.  The new version will not yet be preserved in the Repository, it will be preserved when the databases transactional window is completed, thus when errors arise in the versioning process, the database will be properly kept in its original state and the application will alert that an exception has occurred that is in need of correction.

The Versioning Service will rely on a generica IdentifierService that is described below for minting and registering any identifiers that are required to track the revision history of the Items.

Identifier Service

The Identifier Service maintains an extensible set of IdentifierProvider services that are responsible for two important activities in Identifier management:

1. Minting: Minting is the act of reserving and returning an identifier that may be used with a specific DSpaceObject.
2. Registering: Registering is the act of recording the existence of a minted identifier with an external persistent resolver service, these services may reside ont he local machine (HandleManager) or exist as external services (PURL or DEZID DOI registrations services)

The IdentifierProviders are also responsible for altering any existing DSpace metadata fields that need to be altered on the new and previous items to record the relationship between Item Versions.

Technical Storage Considerations

• Should Versions and VersionHistories are stored in separate tables from the Items
• Version and VersionHistory may be stored in Metadata, but for referential integrity, the system will not rely on this metadata, and instead utilize the version history tables to maintain version relationships.
• Previous versions will exist separately from the latest version in the Item table. This will be allow versions of items to be processed by curation tools, mediafilters, search and browse indexes and AIP backup tools.

Administrative Interface possibilities

Versioning edits to an Item

With a full feature versioning capability on Items, we may possibly be able to support restoration of Item Versions through an interface such as this WIKI page example interface.

Image Removed

Versioning an individual Bitstream on an Item

Versioning individual Bitstreams can be comparable to versioning attachements to a wiki.

Image Removed

Further Scenarios

• Deleting an Item from the Repository
• Moving and Item Between Collections
• Mapping an Item to another collection

Previous WIKI Page needing integration into above...

Versioning Services will layer on top of planned Resolver and Identifier Minting services to provide a layering of functionality where organizations can alter the versioning behavior and introduce their own enhancements:

Versioning Interaction with existing DSpace Systems

Start a new version

• Versioning a new Item will be anOption on the "Context Menu".
• Action will Create a New Item and place it into the Submission Workflow.
• In Navigation.java for Item Versioning we will introduce the following new  

  Code Block
  context.addItem().addXref(contextPath+"/admin/newversion?itemID="+item.getID(), T_context_version_item);

Call to create new Item will be issued to the VersionService as.

ItemVersioningService vs = new DSpace().getServiceManager().getServiceByName(null, ItemVersioningService.class);

Item newVersion = vs.createNewVersion(item);

Call will be initiated from the JAvascript Administrative Controller. ( We may need to come up woth strategy for implementation of calls into the ServiceManager from the Controller.)

/**
Start versioning a new item.
*/
function startVersionItem()
{
var itemID = cocoon.request.get("itemID");
// verify we can create a new version
assertVersionItem(itemID);

// creates a new versioin in the submission workflow.
var newItemID = new DSpace().getServiceManager()....doVersionItem(itemID);

//restart editing new item as if it were part of the submission workflow.
var newItem = Item.find(getDSContext(),itemID);

cocoon.redirectTo(cocoon.request.getContextPath()+"/submit/"+newItem.getHandle(),true);
getDSContext().complete();
item = null;
cocoon.exit();
}

Code approach in GSoC Versioning project

In ArchiveManager (Possible methods for VersioningService) the following code will create a new Version of our Item and Place it into the Submission Workflow

• Separate New Versions of an Item May be started
• Can only one new version be started, until it has been finalized?
• Should the new version of the data package, data files, and bitstreams be processed in the submission and/or reviewing workflow?
• Should information about the revision be hidden until approved?
• Should the handle of a replaced item automatically point to the latest version?

  Code Block

  /**     * Creates a Item in the database that maintains all the same     * attributes and metadata as the Item it supplants with a new     * revision number and a link to the given Item as the previousRevision     * a new bitstream is not created     *     * This Item is ready to be put into the Workspace or a Workflow     *     * @param item The Item to create a new version of     */     public static Item newVersionOfItem(Context context, Item originalItem)     {        try         {             ArchiveManager am = new ArchiveManager();             ItemDAO itemDAO = ItemDAOFactory.getInstance(context);             WorkspaceItemDAO wsiDAO = WorkspaceItemDAOFactory.getInstance(context);             Item item = itemDAO.create();             Item head = itemDAO.getHeadRevision(originalItem.getOriginalItemID());             item.setArchived(false);             item.setWithdrawn(originalItem.isWithdrawn());            // Done by ItemDAO.update ... item.setLastModified();             item.setOriginalItemID(originalItem.getOriginalItemID());             item.setRevision(head.getRevision()+1);             item.setPreviousItemID(head.getID());            //System.out.println("Head: " + head.toString());             item.setOwningCollectionId(originalItem.getOwningCollection().getID());             item.setSubmitter(originalItem.getSubmitter().getID());             item.setMetadata(originalItem.getMetadata());            // Add uri as identifier.uri DC value             item.clearMetadata("dc", "identifier", "uri", null);                        for (Bundle bundle : originalItem.getBundles())             {                 item.addBundle(am.dupeBundle(context, bundle));             }             itemDAO.update(item);             wsiDAO.create(item);            return item;         }        catch (Exception e)         {             throw new RuntimeException(e);         }     } /**     *  Takes in a bundle and makes a deep copy of it.     *  Without duping bitstreams.     *     *  @param bundle     */     private Bundle dupeBundle (Context context, Bundle bundle)     throws AuthorizeException     {         BundleDAO bdao = BundleDAOFactory.getInstance(context);         Bundle dupe = bdao.create();         Bitstream[] bitstreams = null;         int primary = bundle.getPrimaryBitstreamID();         bitstreams = bundle.getBitstreams();        for (Bitstream b : bitstreams)         {             dupe.addBitstream(b);            if (primary == b.getID())             {                 dupe.setPrimaryBitstreamID(b.getID());             }         }         dupe.setName(bundle.getName());        return dupe;     } }

Versioning of item metadata

• Given this is logical versioning (or editioning). Both tThe metadata and bitstream contents for any Item Version in a VersionHistory can be altered.

Versioning of files

• If no files are altered, preferable reference to same bitstream without duplication
• If a new file is being uploaded, or a file is replaced by a URL, the new data file will no longer reference to the file
• Should URL's for files remain the same if the file didn't change?

Two User Stories

Simple Item Versioning Case

The first example is most basic and involves providing a means to request a new version of an Item. When request in the API

public interface VersioningService
{
    public Version<T> getPropertyAsType(T original);
}

Will be used by the application in the following manner:

Item item = ....

String dsoId = "dso:item/" + item.getId();

Verison<Item> itemVersion = new DSpace().getServiceManager().getService(VersioningService.class).createNewVersion(item);

In the simplest Usecase, a new Version of an item will be created, it will have the following characteristics:

New version relationships

Previous Version

We need to consider that the criteria for what constitues a verion of an Item will evolve with the feature and usage. But we have a basic agreement that usage of fields such as the following will be critical for versioning.

• http://dublincore.org/documents/dcmi-terms/#terms-replaces
• http://dublincore.org/documents/dcmi-terms/#terms-isReplacedBy
• http://dublincore.org/documents/dcmi-terms/#terms-isVersionOf
• http://dublincore.org/documents/dcmi-terms/#terms-hasVersion

Where isReplacedBy and Replaces will link individual nodes in the version history while isVersionOf should be sufficient to identify an "original version history thread" for an Item.

The Versioning System should repurpose the identifier generated as values by the MintingService and ResolverService. This will allow the underlying identifer types to be changed out as desired while encapsulating the versioning logic cleanly wihtin the VersioningService.

Complex Item Case (Dryad Composite DataPackage/DataFile versioing)

TODO (feel free to expand on)

See For Further detail: \[\[\]\]

To clarify a little on the last point. We will probably be adjusting the handleManager to assure that we may have a handle specific tot he most current item that can be assigned separately from the current versions handle.

The current logic in reassigning a handle is the following:

1.) The item associated with the handle in the HandleManager is changed.
2.) The item metadata in dc.identifier.uri is updated

If we generate a separate version handle that always points at the most current, it would reside in a separate metadata field (dc.relation.isVersionOf) and would not be altered across versions.

We may consider using dc.relation.replaces / isReplacedBy for pointing backwards/forwards in the version history. If we do not use dc.relation.isReplaced by and just usedc.relation.replaces, we can avoid altering the original metadata record. But there is still some question in my mind to the importance of flagging that the current item has been "replaced"

Both DOI and Handle usecases require that a persistent id be created that represents the latest version of the Item. Ideally, this would be both calculated and serialized int he metadata in a manner to reduce having to update previous items when new items are added. this means that a VersionHistory identifier may not actually be "unique" in our metadata, but that calculating which version to return would always return the most recent.

For Item doi:10.651/dryad.154

At this time, the HandleManager simply assigns a handle to an Item in DSpace, the adjustment that will need to be made is that whenever a new version is generated, the handle representing the version stream (hdl:1234.5/1) will need to be moved to the new Item, however, because it by definition is the identifier for the VersionHistory, and will always resolve the most current version, no, item metadata will need to be updated to reflect that change. This handle should be used when citing the most current version of the item.

If we were to use dc.relation.replaces and dc.relation.isVersionOf to identify both the VersionHistory and and not dc.relation.isReplacedBy to resolve

Tasks needing to be completed To support Versioning of Items:

Database Schema

Task: Create Database changes to support version history/version, similar to Workspaceitem / workflowitem

Task: Document Database Changes here:

Domain Model and Data Access Support Changes

Task: Create Data access objects and domain model to get versions from database

Task: Document Domain Model Here

Task: Utilize ServiceManager to deliver Versioning Service to Application,

Task: Provide Examples of how Service Manager is used to get Service here

XMLUI Support

Task: We will create a new Versioning Aspect Project for changes to XMLUI

Extensible ItemAdapter

Task: Extend the ItemAdapter to have a "administrativeMetadata" section, it would be good if this was pluggable.

To get to here we need review the ItemAdapter overrides that are available in atmire-xmlui-api...

https://atmire.com/svn/modules/dspace-atmire-xmlui/trunk/dspace-atmire-xmlui-api/src/main/java/org/dspace/app/xmlui/objectmanager/

Express Administrative Versioning Metadata in METS Administrative Section of

http:_//host/xmlui/metadata/handle/1234.5/102/mets.xml

<METS:METS .... ID="1234.5/102">

<METS:amdSec ID="RELS-EXT" STATUS="A">
    <METS:techMD ID="VERSION-HISTORY-0.1">
        <METS:mdWrap LABEL="DSpace Version Metadata" MDTYPE="OTHER"
                     FORMAT_URI="info:dspace/foobar"
                     MIMETYPE="application/rdf+xml" OTHERMDTYPE="UNSPECIFIED">
            <METS:xmlData>
                <rdf:RDF xmlns:dc="http://purl.org/dc/elements/1.1/"
                         xmlns:terms="http://purl.org/dc/terms"
                         xmlns:myns="http://www.nsdl.org/ontologies/relationships#"
                         xmlns:oai_dc="http://www.openarchives.org/OAI/2.0/oai_dc/"
                         xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
                         xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#">

                    <rdf:Description rdf:about="hdl:1234.5/100">
                        <dc:identifier>1.1</dc:identifier>
                        <dc:description>Summary of New Version</dc:description>
                        <dc:creator>mdiggory@gmail.com</creator>
                        <terms:created>2011-01-01::12:12:12Z...</terms:created>
                        <terms:isReplacedBy rdf:resource="hdl:1234.5/101"/>
                    </rdf:Description>

                    <rdf:Description rdf:about="hdl:1234.5/101">
                        <dc:description>Summary of New Version</dc:description>
                        <dc:creator>mdiggory@gmail.com</creator>
                        <terms:created>2011-01-01::12:12:12Z...</terms:created>
                        <dc:identifier>1.2</dc:identifier>
                        <terms:replaces rdf:resource="hdl:1234.5/100"/>
                        <terms:isReplacedBy rdf:resource="hdl:1234.5/102"/>
                    </rdf:Description>

                    <rdf:Description rdf:about="hdl:1234.5/102">
                        <dc:description>Summary of New Version</dc:description>
                        <dc:identifier>1.3</dc:identifier>
                        <dc:creator>mdiggory@gmail.com</creator>
                        <terms:created>2011-01-01::12:12:12Z...</terms:created>
                        <terms:replaces rdf:resource="hdl:1234.5/101"/>
                        <terms:isReplacedBy rdf:resource="hdl:1234.5/103"/>
                    </rdf:Description>

                    <rdf:Description rdf:about="hdl:1234.5/103">
                        <dc:identifier>1.4</dc:identifier>
                        <dc:description>Summary of New Version</dc:description>
                        <dc:creator>mdiggory@gmail.com</creator>
                        <terms:created>2011-01-01::12:12:12Z...</terms:created>
                        <terms:replaces rdf:resource="hdl:1234.5/102"/>
                    </rdf:Description>

                </rdf:RDF>

            </METS:xmlData>
        </METS:mdWrap>
    </METS:techMD>
</METS:amdSec>

Utilize DC and DC TERMS where appropriate for time being.

http://dublincore.org/documents/2008/01/14/dcmi-terms/#terms-isVersionOfhttp://dublincore.org/documents/2008/01/14/dcmi-terms/#terms-hasVersionhttp://dublincore.org/documents/2008/01/14/dcmi-terms/#terms-isReplacedBy

we will decide on more fields, document in the wiki page.

Rendering to HTML

Task: Add Versioning DIV section to ItemView rendering the RDF admMeta section in the mets doc.

Actions in XMLUI

Task: Add Administrative Option in Item Edit View to create a new versioin

Task: New Version should go into WorkspaceItem table of whomever created it and be opened in the Submission workflow for the user to edit metadata and bitstreams.

Reviewer Workflow Step

Identify in Reviewer Workflow Step how to address the new Item.

Curator Workflow Step

Identify on Curator Workflow Step will render that Item is an New Version.

Add To Archive

TBD, Should replacement of the previous version in the archive be determined by user? Examples:

...