Page History

...

Versioning is a new functionality to build the history of an item. Users will have the opportunity to create new version of an existing item any time the will make a change.

Enabling Item Level Versioning

By default, Item Level Versioning is disabled in DSpace 3.0.  This feature is currently only supported in the XMLUI.

If you wish to enable this feature, you just have to uncomment the "Versioning" aspect in your [dspace]/config/xmlui.xconf file (and restart your servlet container):

<!-- =====================
     Item Level Versioning
     ===================== -->
<!-- To enable Item Level Versioning features, uncomment this aspect. -->
<aspect name="Versioning Aspect" path="resource://aspects/Versioning/" />

Important warnings - read before enabling

Enabling Item Level Versioning

By default, Item Level Versioning is disabled in DSpace 3.0/4.0.

Steps for XML UI

If you wish to enable this feature, you just have to uncomment the "Versioning" aspect in your [dspace]/config/xmlui.xconf file (and restart your servlet container):

<!-- =====================
     Item Level Versioning
     ===================== -->
<!-- To enable Item Level Versioning features, uncomment this aspect. -->
<aspect name="Versioning Aspect" path="resource://aspects/Versioning/" />

Steps for JSP UI

If you wish to enable this feature, you just have to edit the  enabled  settings in your [dspace]/config/modules/versioning.cfg file (and restart your servlet container):

#---------------------------------------------------#
#------------ VERSIONING CONFIGURATIONS ------------#
#---------------------------------------------------#
#  These configs are used by the versioning system  #
#---------------------------------------------------#
#Parameter 'enabled' is used only by JSPUI
enabled=false

Initial Requirements

The Item Level Versioning implementation in DSpace 3.0 builds on following requirements identified by the stakeholders who supported this contribution: Initial Requirements Analysis

...

1. Resolution: IdentifierService act in a manner similar to the existing 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 .  These services may reside on the local machine (HandleManager) or exist as external services (PURL or DEZID EZID DOI registrations registration services)

   Code Block
   language java
   public interface IdentifierService { /** * * @param context * @param dso * @param identifier * @return */ String lookup(Context context, DSpaceObject dso, Class<? extends Identifier> identifier); /** * * This will resolve a DSpaceObject based on a provided Identifier. The Service will interrogate the providers in * no particular order and return the first successful result discovered. If no resolution is successful, * the method will return null if no object is found. * * TODO: Verify null is returned. * * @param context * @param identifier * @return * @throws IdentifierNotFoundException * @throws IdentifierNotResolvableException */ DSpaceObject resolve(Context context, String identifier) throws IdentifierNotFoundException, IdentifierNotResolvableException; /** * * Reserves any identifiers necessary based on the capabilities of all providers in the service. * * @param context * @param dso * @throws org.dspace.authorize.AuthorizeException * @throws java.sql.SQLException * @throws IdentifierException */ void reserve(Context context, DSpaceObject dso) throws AuthorizeException, SQLException, IdentifierException; /** * * Used to Reserve a Specific Identifier (for example a Handle, hdl:1234.5/6) The provider is responsible for * Detecting and Processing the appropriate identifier, all Providers are interrogated, multiple providers * can process the same identifier. * * @param context * @param dso * @param identifier * @throws org.dspace.authorize.AuthorizeException * @throws java.sql.SQLException * @throws IdentifierException */ void reserve(Context context, DSpaceObject dso, String identifier) throws AuthorizeException, SQLException, IdentifierException; /** * * @param context * @param dso * @return * @throws org.dspace.authorize.AuthorizeException * @throws java.sql.SQLException * @throws IdentifierException */ void register(Context context, DSpaceObject dso) throws AuthorizeException, SQLException, IdentifierException; /** * * Used to Register a Specific Identifier (for example a Handle, hdl:1234.5/6) The provider is responsible for * Detecting and Processing the appropriate identifier, all Providers are interrogated, multiple providers * can process the same identifier. * * @param context * @param dso * @param identifier * @return * @throws org.dspace.authorize.AuthorizeException * @throws java.sql.SQLException * @throws IdentifierException */ void register(Context context, DSpaceObject dso, String identifier) throws AuthorizeException, SQLException, IdentifierException; /** * Delete (Unbind) all identifiers registered for a specific DSpace item. Identifiers are "unbound" across * all providers in no particular order. * * @param context * @param dso * @throws org.dspace.authorize.AuthorizeException * @throws java.sql.SQLException * @throws IdentifierException */ void delete(Context context, DSpaceObject dso) throws AuthorizeException, SQLException, IdentifierException; /** * Used to Delete a Specific Identifier (for example a Handle, hdl:1234.5/6) The provider is responsible for * Detecting and Processing the appropriate identifier, all Providers are interrogated, multiple providers * can process the same identifier. * * @param context * @param dso * @param identifier * @throws org.dspace.authorize.AuthorizeException * @throws java.sql.SQLException * @throws IdentifierException */ void delete(Context context, DSpaceObject dso, String identifier) throws AuthorizeException, SQLException, IdentifierException; }

...

item.history.view.admin=false

Identified Challenges & Known Issues in DSpace

...

4.0

Item Level Versioning has a substantial conceptual impact on many DSpace features. Therefore it has been accepted into DSpace 3.0 as an optional feature and it is still an option feature in DSpace 4.0. Following challenges have been identified in the current implementation. As an early adopter of the Item Level Versioning feature, your input is greatly appreciated on any of these.

...

One possible solution would be to present an end user with aggregated statistics across all viewers, and give administrators the possibility to view statistics per version.

No support for JSP User Interface

Item Versioning in DSpace 3.0 was contributed without specific user interface support for JSP User Interface.

Exposing version history

The version history is added on the bottom of a versioned item page. A repository administrator can either decide to show this to all users, or restrict it to admins only. If it is shown to admins only, an end user will have no way to find the way to an older version. On the other hand, if a repository administrator does decide to expose version history to all users, the name and email address of the editor are exposed as well. This might actually be useful if the editor account is a generic institutional email address, but may conflict with local privacy laws if any personal details are included in this account.

...

• MBLWHOI Library
• Woods Hole Oceanographic Institution
• Marine Biology Laboratory, Center for Library and Informatics, History and Philosophy of Science program
• Arizona State University, Center for Biology and Society
• Dryad

The JSP UI compatibility has been added in DSpace 4.0 by CINECA