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 Data Package Items will utilize versioning capabilities already inside the DOI service used to mint DOI's (written by Kevin Clark)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:

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

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

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

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

Item Type	Package 1	Start Package 2 (Before Submission)	Edit Package 2 (DataFile Change During Submission)
Package DOI	doi:10.561/dryad.154.1
	Package Version 1	Package Version 2	Package Version 3
dc.identifier	doi:10.651/dryad.154.1	doi:10.561/dryad.154.2	doi:10.561/dryad.154.3
dc.relation.isReplacedBy	doi:10.561/dryad.154.2	doi:10.561/dryad.154.3	dc.relation.replaces	2	doi:10.561/dryad.154.2
Data File 1 DOI	doi: doi.10.561/dryad.154.1/1.1	doi:10.561/dryad.154.2

The solution will also apply to individual Data Files when it is designated that the Data File is being replaced in the Data Package rather than being simply removed.

/1.1
	File Version 1	File Version 2	File Version 3
dc.identifier	doi:10.651561/dryad.154.12/1.1 2
Data File 2 DOI	doi:10.561/dryad.154.1/2/.1 .2	doi:10.561/dryad.154.32/2.1 .3	dc.relation.isReplacedBy	doi:10.561/dryad.154.2/2.1 .2

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

	Item 1	= Start Item 2 (On Submission or SWORD Update)
Item Version DOI Identifier	doi doi:10.561/dryad.154.3/1 .3 dc.relation.replaces		doi.:10.561/dryad.154.1/12
Item Version Handle Identifier	hdl:10.561/154.1	doi hdl:10.561/dryad.154.2/1.2

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:

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

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

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

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

Item Type	Package 1	Start Package 2 (Before Submission)	Edit Package 2 (DataFile Change During Submission)
Package DOI	doi:10.561/dryad.154.1	doi:10.561/dryad.154.2	doi:10.561/dryad.154.2
Data File 1 DOI	doi:10.561/dryad.154.1/1.1	doi:10.561/dryad.154.2/1.1	doi:10.561/dryad.154.2/1.2
Data File 2 DOI	doi:10.561/dryad.154.1/2.1	doi:10.561/dryad.154.2/2.1	doi:10.561/dryad.154.2/2.1

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

	Item 1	= Start Item 2 (On Submission or SWORD Update)
Item Version DOI Identifier	doi:10.561/dryad.154.1	doi:10.561/dryad.154.2
Item Version Handle Identifier	hdl:10.561/154.1	hdl:10.561/154.2

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:

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. This may give rise to unexpected behavior in some of the DSpaceObject Code that retrieves the Parent Item from the Bitstream

DSpace Bitstream Objects:

Image Removed

Business Model

Image Removed

Versioning Service

Identifier Service

Storage Considerations

Should Versions and VersionHistories maybe be stored in separate tables from Items considered part of repository?
Version and VersionHistory may not be stored in Metadata, but instead calculated and added as additional metadata in the item?
Will previous versions of items be represented separately from the latest version in the Item table? This will be required for methods based on finding all items to be indexed, batch exported, updated by MediaFilter, ...
- Using a separate column: latestVersion?
- Using the in_archive column?

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.

Code Block
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.)

Code Block

/**
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

Code Block

language	java

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

Will be used by the application in the following manner:

Code Block
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

Field	Value (Relationship)
dc.identifer.uri	<new-handle>
dc.relation.isVersionOf	<original-handle>
dc.relation.replaces	<previous item> (identifier of previous version)

Previous Version


dc.identifer.uri	<previous-handle>
dc.relation.isVersionOf	<original-handle>
dc.relation.isreplacedby	<new item> (Identifer of new Item)

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.

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)

Wiki Markup
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"

as we discussed last Friday

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


dc.identifier	doi:10.651/dryad.154.2	For the next version
dc.relation.isVersionOf	doi:10.651/dryad.154	should be present in all Items in VersionHistory, will be used to look up the entire version history
dc.relation.replaces	doi:10.651/dryad.154.1	Will be used to trace the Revision Tree.


dc.identifier	doi:10.651/dryad.154.1

For Item doi:10.651/dryad.154

For the next version (doi:10.651/dryad.154.2)
dc.identifier: doi:10.651/dryad.154.2
dc.relation.isVersionOf: doi:10.651/dryad.154 <--- should be present in all Items in VersionHistory, will be used to look up the entire version history
dc.relation.replaces: doi:10.651/dryad.154.1 <--- Will be used to trace the Revision Tree.

Where the previous version would have (doi:10.651/dryad.154.1)
dc.identifier: doi:10.651/dryad.154.1
dc.relation.isVersionOf: doi:10.651/dryad.154 <--- should be present in all Items in VersionHistory, will be used to look up the entire version history
dc.relation.isReplacedBy: doi:10.651/dryad.154.2--

IN the Handle approach for this will look like

For the next version (hdl:1234.5/3)
dc.identifier: hdl:1234.5/2
dc.relation.isVersionOf: hdl:1234.5/1 <--- should be present in all Items in VersionHistory, will be used to look up the entire version history
dc.relation.hasVersion: hdl:1234.5/2
dc.relation.replaces: hdl:1234.5/2 <--- Will be used to trace the Revision Tree.

Where the previous version (hdl:1234.5/2) would have
dc.identifier: hdl:1234.5/2
dc.relation.isVersionOf: hdl:1234.5/1 <--- should be present in all Items in VersionHistory, will be used to look up the entire version history
dc.relation.isReplacedBy: hdl:1234.5/3--

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

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 Added

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 Added

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:

Minting: Minting is the act of reserving and returning an identifier that may be used with a specific DSpaceObject.
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 Added

Versioning an individual Bitstream on an Item

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

Image Added

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.

Code Block
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.)

Code Block

/**
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

Code Block

language	java

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

Will be used by the application in the following manner:

Code Block
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

Field	Value (Relationship)
dc.identifer.uri	<new-handle>
dc.relation.isVersionOf	<original-handle>
dc.relation.replaces	<previous item> (identifier of previous version)

Previous Version


dc.identifer.uri	<previous-handle>
dc.relation.isVersionOf	<original-handle>
dc.relation.isreplacedby	<new item> (Identifer of new Item)

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.

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)

Wiki Markup
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

Code Block

language	html/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

Code Block

language	html/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:termsFORMAT_URI="httpinfo://purl.org/dc/termsdspace/foobar"
                         xmlns:myns="http://www.nsdl.org/ontologies/relationships#"
MIMETYPE="application/rdf+xml" OTHERMDTYPE="UNSPECIFIED">
            <METS:xmlData>
                <rdf:RDF xmlns:oai_dc="http://wwwpurl.openarchives.org/OAIdc/elements/2.0/oai_dc1.1/"
                         xmlns:rdfterms="http://wwwpurl.w3.org/1999/02/22-rdf-syntax-ns#dc/terms"
                         xmlns:rdfsmyns="http://www.w3nsdl.org/2000/01/rdf-schema#">

ontologies/relationships#"
                        <rdf:Description rdfxmlns:aboutoai_dc="hdl:1234.5/100">http://www.openarchives.org/OAI/2.0/oai_dc/"
                        <dc:identifier>1.1</dc:identifier> xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
                        <dc:description>Summary of New Version</dc:description> xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#">

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

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

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

<dc:identifier>1.2</dc:identifier>
                        <rdf<terms:Descriptionreplaces rdf:aboutresource="hdl:1234.5/102100"/>
                        <dc<terms:description>Summary of New Version</dc:description>isReplacedBy rdf:resource="hdl:1234.5/102"/>
                        <dc:identifier>1.3</dc:identifier>
   </rdf:Description>

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

created>
                        <rdf<terms:Descriptionreplaces rdf:aboutresource="hdl:1234.5/103101"/>
                        <dc:identifier>1.4</dc:identifier><terms:isReplacedBy rdf:resource="hdl:1234.5/103"/>
                        <dc:description>Summary of New Version<</dcrdf:description>Description>

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

                </rdf:RDF>
<dc:creator>mdiggory@gmail.com</creator>
            </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-isVersionOf http://dublincore.org/documents/2008/01/14/dcmi-terms/#terms-hasVersion http://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:

Withdraw Previous Item From Search and View
Withdraw Previous Item For Search Only

Dryad Hierarchical Identification Usecase

Dyrad will expose semantic detail on the version of an Identifier by encoding it in the DOI. This DOI will have the following structure.

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

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

Item Type	Package 1	Start Package 2 (Before Submission)	Edit Package 2 (DataFile Change During Submission)
Package DOI	doi:10.561/dryad.154.1	doi:10.561/*dryad.154.2*	doi:10.561/dryad.154.2
Data File 1 DOI	doi:10.561/dryad.154.1/1.1	doi:10.561/*dryad.154.2*/1.1	doi:10.561/dryad.154.2/*1.2*
Data File 2 DOI	doi:10.561/dryad.154.1/2.1	doi:10.561/*dryad.154.2*/2.1	doi:10.561/dryad.154.2/2.1

Development Tasks:

Alter DOI Service (Minter.java mintDOI method) to support the following:

Calculate Dryad DataPackage version from DataPackage versionhistory and record into db
Calculate Dryad DataFile version from DataFile versionhistory and record into dd

Alter DSpace Submission to support the following:

...

<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-isVersionOf http://dublincore.org/documents/2008/01/14/dcmi-terms/#terms-hasVersion http://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:

Withdraw Previous Item From Search and View
Withdraw Previous Item For Search Only

...

Page tree

Page History

Versions Compared

Old Version 10

New Version 11

Key

Versioned Identifiers in DOI Service

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

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

Versioned Identifiers in DOI Service

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

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

DSpace Data Model and Versioning

DSpace Item Objects:

DSpace Bundle Objects:

DSpace Bitstream Objects:

Business Model

Versioning Service

Identifier Service

Storage Considerations

Administrative Interface possibilities

Versioning edits to an Item

Versioning an individual Bitstream on an Item

Further Scenarios

Versioning Interaction with existing DSpace Systems

Start a new version

Code approach in GSoC Versioning project

Versioning of item metadata

Versioning of files

Two User Stories

Simple Item Versioning Case

New version relationships

Previous Version

Complex Item Case (Dryad Composite DataPackage/DataFile versioing)

as we discussed last Friday

Tasks needing to be completed To support Versioning of Items:

Database Schema

Domain Model and Data Access Support Changes

XMLUI Support

Extensible ItemAdapter

DSpace Data Model and Versioning

DSpace Item Objects:

DSpace Bundle Objects:

DSpace Bitstream Objects:

Business Model

Versioning Service

Identifier Service

Technical Storage Considerations

Administrative Interface possibilities

Versioning edits to an Item

Versioning an individual Bitstream on an Item

Further Scenarios

Versioning Interaction with existing DSpace Systems

Start a new version

Code approach in GSoC Versioning project

Versioning of item metadata

Versioning of files

Two User Stories

Simple Item Versioning Case

New version relationships

Previous Version

Complex Item Case (Dryad Composite DataPackage/DataFile versioing)

Tasks needing to be completed To support Versioning of Items:

Database Schema

Domain Model and Data Access Support Changes

XMLUI Support

Extensible ItemAdapter

Rendering to HTML

Actions in XMLUI

Reviewer Workflow Step

Curator Workflow Step

Add To Archive

Dryad Hierarchical Identification Usecase

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

Development Tasks:

Rendering to HTML

Actions in XMLUI

Reviewer Workflow Step

Curator Workflow Step

Add To Archive