Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Moving Web UI up, because more people will want to read that first.

...

  1. What should be Versionable
    1. Versioning happens at the level of an Individual Item
    2. Versioning should preserve the current state of metadata, bitstreams and resource policies attached to the item.
  2. Access, Search and Discovery
    1. Only the most recent version of an item is available via the search interface
    2. Previous versions of Items should continue to be visible, citable and accessible 
    3. The Bitstreams for previous versions are retained. If something was once retrievable, it should always be retrievable.
  3. Identifiers
    1. Each version of an Item is represented by a separate "versioned" identifier
    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.
  4. Presentation
    1. On the item page, there is a link to view previous/subsequent versions.
    2. 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.
  5. Access Control and Rights
    1. Certain roles should be able to generate a new version of the item via submission.
    2. To submitters, collection manager, administrators will be given to option to create new version of an  item.
    3. Rights to access a specific Item should transmute as well to previous versions
    4. Rights to access a specific Bitstream should also transmute to previous versions.
  6. 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.

Versioning model

For every new Version a separate DSpace Item will be created that replicates the metadata, bundle and bitstream records. The bitstream records will point to the same file on the disk.

Image Removed

The Cleanup method has been modified to retain the file if another Bitstream record point to it, in other words the file will be deleted only if the Bitstream record processed is the only one to point to the file (count(INTERNAL_ID)=1).

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 Removed

Versioning Service

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

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

User Interface

Create a new version of an item

To create a new version of an existing item the following steps have to be performed:

  1. Search for an Item
  2. Go to Item view page
  3. click on "create a new version"
  4. fill out the form and confirm the operation 

Image Added

After the operation is confirmed a new submission process will be generated and the user could modify the metadata and the bitstream(s).
The new version of the item won't be visible until the workflow will be completed.

Access history of an item

To access the history of an item the following steps have to be performed:

  1. Research the Item
  2. Go to Item view page

Versioning model

For every new Version a separate DSpace Item will be created that replicates the metadata, bundle and bitstream records. The bitstream records will point to the same file on the disk.

Image Added

The Cleanup method has been modified to retain the file if another Bitstream record point to it, in other words the file will be deleted only if the Bitstream record processed is the only one to point to the file (count(INTERNAL_ID)=1).

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.

Code Block
public
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);
}

...

Code Block
<?xml version="1.0" encoding="UTF-8"?>
<!--

    Copyright (c) 2002-2010, DuraSpace.  All rights reserved
    Licensed under the DuraSpace License.

    A copy of the DuraSpace License has been included in this
    distribution and is available at: http://www.dspace.org/license

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


    <!-- Versioning Service Application Interface for DSpace Will be autowired with
         a Versioning Provider present in Spring context.
         Default Item Versioning Provider, defines behavior for replicating
         Item, Metadata, BUndles and Bitstreams. Autowired at this time.

    <bean id="org.dspace.versioning.VersioningService"
          class="org.dspace.versioning.VersioningServiceImpl"
          autowire="byType"
          scope="singleton">
        <property name="versionDAO">
            <bean classautowire="org.dspace.versioning.VersionDAO"/>
byType"
          </property>scope="singleton">
        <property name="versionHistoryDAOversionDAO">
            <bean class="org.dspace.versioning.VersionHistoryDAOVersionDAO"/>
        </property>
        <property name="providerversionHistoryDAO">

            <bean class="org.dspace.versioning.DefaultItemVersionProviderVersionHistoryDAO"/>
        </property>

    </bean>
     -->
</beans>

identifier-service.xml:

<property name="provider">

            <bean class="org.dspace.versioning.DefaultItemVersionProvider"/>
        </property>

    </bean>
     -->
</beans>

identifier-service.xml:

Code Block
<?xml version="1.0" encoding="UTF-8"?>
<!--

Copyright (c) 2002-2010, DuraSpace. All rights reserved
Licensed under the DuraSpace License.

A copy of the DuraSpace License has been included in this
distribution and is available at: http://www.dspace.org/license

-->
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-2.5.xsd"
Code Block
<?xml version="1.0" encoding="UTF-8"?>
<!--

Copyright (c) 2002-2010, DuraSpace. All rights reserved
Licensed under the DuraSpace License.

A copy of the DuraSpace License has been included in this
distribution and is available at: http://www.dspace.org/license

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

<!-- Identifier Service Application Interface. Will be autowired with
any Identifier Providers present in Spring context.
-->
<bean id="org.dspace.identifier.IdentifierService"
class="org.dspace.identifier.IdentifierServiceImpl"
autowire="byType"
scope="singleton"/>

<!-- Identifier provider for using the versioned handle identifier instead of the default one. Service Application Interface. Will be autowired with
any Identifier Providers present in Spring context.
-->
<!-<bean id="org.dspace.identifier.HandleIdentifierProviderIdentifierService" 
class="org.dspace.identifier.VersionedHandleIdentifierProvider"->
<!-IdentifierServiceImpl"
autowire="byType"
scope="singleton"/>->

<!-<property name="configurationService" ref="org.dspace.services.ConfigurationService"/>->
<!-</bean>->

</beans>

To enable VersionedHandleIdentifierProvider reinstate it taking off the comment.
VersionedHandleIdentifierProvider will attach the revision number at the end of the item identifier for e.g., the version 3 of the item 12345/123 will be 12345/123.3.

Enable VersionHistory only for Administrator

To set the version history to be seen only by the administrators a property in the versioning.cfg file can be edited:

Code Block
item.history.view.admin=false

User Interface

Create a new version of an item

To create a new version of an existing item the following steps have to be performed:

  1. Search for an Item
  2. Go to Item view page
  3. click on "create a new version"
  4. fill out the form and confirm the operation 

. Image Removed

After the operation is confirmed a new submission process will be generated and the user could modify the metadata and the bitstream(s).
The new version of the item won't be visible until the workflow will be completed.

Access history of an item

To access the history of an item the following steps have to be performed:

...

- provider for using the versioned handle identifier instead of the default one. -->
<!-<bean id="org.dspace.identifier.HandleIdentifierProvider" class="org.dspace.identifier.VersionedHandleIdentifierProvider"->
<!-scope="singleton">->
<!-<property name="configurationService" ref="org.dspace.services.ConfigurationService"/>->
<!-</bean>->

</beans>

To enable VersionedHandleIdentifierProvider reinstate it taking off the comment.
VersionedHandleIdentifierProvider will attach the revision number at the end of the item identifier for e.g., the version 3 of the item 12345/123 will be 12345/123.3.

Enable VersionHistory only for Administrator

To set the version history to be seen only by the administrators a property in the versioning.cfg file can be edited:

Code Block
item.history.view.admin=false

Identified Challenges & Known Issues in DSpace 3.0

...