DSpace Item Level Versioning Support

Introduction

DSpace Item Level Versioning Support is a funded open source activity to bring work done by NESCent and @mire into the DSpace 3.0 Codebase.  Additional partners have signed onto this activity to assure that resources are available to drive Item Versioning Support forward and make it available to the larger DSpace community in the next release.

Stakeholders

Key Stakeholders involved with Item Versioning Support:

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

Business Requirements / Goals

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

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. 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

Goals

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

Requirements

1.  Versioning is at the level of data files. 

2. Wiki Markup
   Data packages and data files have a relationship between their identifiers. Each version of a file/package is represented by a separate DOI. The "base" DOI points to the most recent version of the file/package, but a version number can be added to the base DOI to access previous versions. See the \[\[\]\] page for more details about the DOI format.

3. When a new version of data file is deposited, a new identifier will be created.
4. Adding or changing README files or metadata will not result in creation of a new identifier.
5. All metadata changes are logged by writing a metadata snapshot to the filesystem this allows us to retain a record of the changes, even though they are not available as explicit versions (and not viewable in the UI). - If all we are doing is adding a new bitstream without changing the existing bitstreams, there is no need to force a version number change.
6. When a new identifier is created for a data file, a new identifier is automatically created for the corresponding data package.
7. 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)
   1. Only the most recent version of an item is available via the search interface
   .
8. On the item page, there is a link to view previous/subsequent versions.
9. By examining the metadata, it is possible to determine whether an item is the most recent version, the original version, or an intermediate version.
10. 1. (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.
11. Creation of a new version is initiated by the author. On the "submissions" page, users should see all of their archived submissions. Each archived submission should have a button to submit a new version of a data file - this button doesn't appear anywhere else
12. Expose Versioning detail in DSpace API and Services (I.E. OAI, Bagit, Etc.)

Technical Details

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
  • Actions that should be possible to users (submitter, author, curator)

User Scenarios

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

Metadata Mapping

General Versioning of DSpace Items

Generic Versioning of DSpace Items will involve the alteration of existing handles for those versions in DSpace.

While past recommendation are that identifiers that are assigned to items be opaque, we have two possible benefit from selecting a versioning schedme 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 Data Package will utilize versioning capabilities already inside the DOI service used to mint DOI's (written by Kevin Clark)

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.

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.

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

from ArchiveManager (Possible methods for VersioningService)

/**
     * Gets an Item by its OriginalItemID and Revision numbers
     */
    public static DSpaceObject getVersionedItem(Context context, int originalItemID, int revision)
    {

        return ItemDAOFactory.getInstance(context).getByOriginalItemIDAndRevision(originalItemID, revision);
    }
    
    /**
     * Gets the HEAD of an OriginalItemID
     */
    public static DSpaceObject getHeadRevision(Context context, int originalItemID)
    {

        return ItemDAOFactory.getInstance(context).getHeadRevision(originalItemID);
    }
    
    /**
     * 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;
    }
}

Will Create a New 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?

Versioning of item metadata

The metadata for either a datapackage or a data file can be altered.

• Should all items receive a new version number at once?

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

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"

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

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.

1. Identifiers
   1. Each version of an Item is represented by a separate "versioned" identifier (Handle or DOI)
   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.
2. 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.
3. 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 original submitter. On the "submissions" page, submitter should see all of their archived submissions. 
   3. Collection Manager, Administrators: should have a button to submit a new version of a Item accessible in the Edit Item administrative interface.
   4. Rights to access a specific Item should transmute as well to previous versions
   5. Rights to access a specific Bitstream should also transmute to previous versions.
4. 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

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

Mockups

Item View

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

An example of an initial Version within Dryad

Image Added

Version 2

An example of a second version within Dryad

Image Added

Edit Item and Version Management

[TODO]

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

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

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.

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 generic IdentifierService that is described below for minting and registering any identifiers that are required to track the revision history of the Items.

Dryad Example: Version 1, Version 2 of same document (see versions listed at bottom of page)

Code: Google Code

public interface VersioningService {

    Version createNewVersion(Context c, int itemId);

    Version createNewVersion(Context c, int itemId, String summary);

    void removeVersion(Context c, int versionID);

    void removeVersion(Context c, Item item);

    Version getVersion(Context c, int versionID);

    Version restoreVersion(Context c, int versionID);

    Version restoreVersion(Context c, int versionID, String summary);

    VersionHistory findVersionHistory(Context c, int itemId);

    Version updateVersion(Context c, int itemId, String summary);

    Version getVersion(Context c, Item item);

}

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)

Dryad Example: The same document can be accessed via different identifiers: DOI link (http://dev.datadryad.org/resource/doi:10.5061/dryad.1385.2), Handle link (http://dev.datadryad.org/resource/info:hdl/10255/dryad.36265), default DSpace Link (http://dev.datadryad.org/resource/10255/dryad.36265)

Code: Google Code

Application IdentifierService Interface

public interface IdentifierService {

    void reserve(Context context, Item item) throws AuthorizeException, SQLException, IdentifierException;

    String register(Context context, Item item) throws AuthorizeException, SQLException, IdentifierException;

    DSpaceObject resolve(Context context, String identifier) throws IdentifierNotFoundException, IdentifierNotResolvableException;

    void delete(Context context, Item item) throws AuthorizeException, SQLException, IdentifierException;
}

Backend IdentifierProvider Interface

public abstract class IdentifierProvider {

    protected IdentifierService parentService;

    protected ConfigurationService configurationService;

    @Autowired
    @Required
    public void setConfigurationService(ConfigurationService configurationService) {
        this.configurationService = configurationService;
    }

    public void setParentService(IdentifierService parentService) {
        this.parentService = parentService;
    }

    public abstract boolean supports(String identifier);

    public abstract String register(Context context, DSpaceObject item) throws IdentifierException;

    public abstract String mint(Context context, DSpaceObject dso) throws IdentifierException;

    public abstract DSpaceObject resolve(Context context, String identifier, String... attributes)
         throws IdentifierNotFoundException, IdentifierNotResolvableException;;

    public abstract void delete(Context context, DSpaceObject dso) throws IdentifierException;
}

Example of Spring Configuration for Default HandleProvider Support

http://code.google.com/p/dryad/source/browse/trunk/dryad/dspace/modules/identifier-services/src/main/resources/spring/spring-dspace-core-services.xml

<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:context="http://www.springframework.org/schema/context"
    xsi:schemaLocation="http://www.springframework.org/schema/beans
           http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
           http://www.springframework.org/schema/context
           http://www.springframework.org/schema/context/spring-context-2.5.xsd">

    <bean class="org.dspace.identifier.HandleIdentifierProvider" scope="singleton"/>
    <bean class="org.dspace.identifier.InternalIdentifierProvider" scope="singleton"/>
    <bean class="org.dspace.identifier.IdentifierServiceImpl" 
           id="org.dspace.identifier.IdentifierService" 
           autowire="byType" scope="singleton"/>

</beans>

Addons Can easily add additional Providers without directly needing to alter DSpace Code

See Dryad Specific Identifier and Versioning Services

<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:context="http://www.springframework.org/schema/context"
    xsi:schemaLocation="http://www.springframework.org/schema/beans
           http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
           http://www.springframework.org/schema/context
           http://www.springframework.org/schema/context/spring-context-2.5.xsd">

    <bean class="org.dspace.versioning.DryadPackageVersionProvider" autowire="byType"/>
    <bean class="org.dspace.identifier.DOIIdentifierProvider" scope="singleton"/>

</beans>

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.

Support for resolving identifiers via DSpace User Interface

The Resource Path "/resource/..."

Dryad supports a unique identifier resolving service based on Spring WebMVC which allows Identifiers registered within the IdentifierServices to be dereferenced to varied representations of the actual DSpace Items. This resolution can span dspace to alternative webapplications to support various representation formats. The mechanism is extendable in the XMLUI and will be utilized to support dereferencing identifiers via content negotiation to expose alternative format representations of the Item, in Dryad the following are currently implemented.

Basic XMLUI HTML Representation

http://dev.datadryad.org/resource/doi:10.5061/dryad.r460n.2

http://dev.datadryad.org/resource/info:hdl/10255/dryad.39114

http://dev.datadryad.org/resource/10255/dryad.39114

Image Added

RIS Representation

http://dev.datadryad.org/resource/doi:10.5061/dryad.r460n.2/citation/ris

TY  - DATA
ID  - doi:10.5061/dryad.r460n.2
T1  - Data from: Testing embargo
AU  - Feinstein E(
Y1  - 2012/04/30/
JF  - Testing journal
PB  - Dryad Data Repository
UR  - http://dx.doi.org/10.5061/dryad.r460n.2
DO  - doi:10.5061/dryad.r460n.2
ER  -

BibTex Representation

http://dev.datadryad.org/resource/doi:10.5061/dryad.r460n.2/citation/bib

@misc{dryad_r460n_2,
  title = {Data from: Testing embargo},
  author = {Feinstein, E(},
  year = {2012},
  journal = {Testing journal},
  URL = {http://dx.doi.org/10.5061/dryad.r460n.2},
  doi = {doi:10.5061/dryad.r460n.2},
  publisher = {Dryad Digital Repository}
}

...