Page History
DSpace Item Level Versioning Support
Table of Contents |
---|
Info | ||
---|---|---|
| ||
This page contains an initial requirements analysis for the Item Level Versioning Support, contributed to DSpace 3.0. Refer to the official DSpace 3 documentation for the most up to date information on Item Level Versioning. |
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.
...
Key Stakeholders involved with Item Versioning Support:
- Mark Diggory - @mire
- Holly Miller - MBL
- Diane Rielinger - MBL
- Lisa Raymond - WHOI
- Ryan Scherle - NESCent / Dryad
...
Higher Priority Requirements
- What is Versionable
- Versioning is at the level of
- an Individual Item
- Should preserve the current state of metadata, bitstreams and resource policies attached to the item.
- Access, Search and Discovery
- Only the most recent version of an item is available via the search interface (possibly configurable)
- Previous Versions of Items should continue to be visible, citable and accessible
- The Previous
- Versions Bitstreams are retained. If something was once retrievable, it is always retrievable.
- Identifiers
- Each version of an Item is represented by a separate "versioned" identifier (Handle or DOI
- The relationships between versions should be visible in various Metadata Exports (OAI, Packagers, ItemExport)
- Expose Versioning detail in DSpace API and Services (I.E. OAI, Bagit, Etc.
- )
- The relationships between versions should not be brittle and breakable by manipulating Item metadata records.
- A base "versionhistory" Identifier points to the most recent version of the Item.
- A revision identifier also exists that is unique to the specific version.
- When a new version of an Item is deposited, a new revision identifier will be created.
- When a new version of an Item is deposited the "versionhistory" identifier will resolve to the new version.
- 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)
- Presentation
- On the item page, there is a link to view previous/subsequent versions.
- Each version of the item should include additional provenance details about who created the version, when and why.
- 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.
- Access Control and Rights
- Certain roles should be able to generate a new version of the item via submission, sword or LNI deposit.
- Submitters: Creation of a new version is initiated by the
- original submitter. On the "submissions" page,
- submitter should see all of their archived submissions.
- Collection Manager, Administrators: should have a button to submit a new version of a
- Item accessible in the Edit Item administrative interface.
- Rights to access a specific Item should transmute as well to previous versions
- Rights to access a specific Bitstream should also transmute to previous versions.
- Data Integrity
- The relationships between versions should not be brittle and breakable by manipulating Item metadata records.
- The relationships between versions should be preserved and predictable in various Metadata Exports (OAI, Packagers, ItemExport)
- The relationships between versions should be maintained in SWORD, LNI and AIP packaging and be maintained in updates and restorations.
Lower Priority Requirements
- 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.
Examples of Items with an additional Item Version Attached
Version 1
An example of an initial Version within Dryad
Version 2
An example of a second version within Dryad
Edit Item and Version Management
[TODO]
Technical Requirements and Existing Implementation
...
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.
Services to support Versioning and Alternative Identifiers.
DSpace 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 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
Code Block |
---|
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:
- Resolution: IdentifierService act in a manner similar to the exisitng HandleManager in DSpace, allowing for resolution of DSpace Items from provided identifiers.
- 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)
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
Code Block | ||
---|---|---|
| ||
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
...
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.
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.
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.
Examples of Items with an additional Item Version Attached
Version 1
An example of an initial Version within Dryad
Version 2
An example of a second version within Dryad
Code Block |
---|
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
Code Block |
---|
<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
Code Block |
---|
<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.Edit Item and Version Management
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.
...