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.
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.
- Release of a new scientific dataset with additional data
- Release of a corrected scientific dataset with altered data
- Release of a revised or corrected journal article, technical report, ...
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)
- 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.
- 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
Goals
The history of an item should be available, and it should be possible to cite a particular version of the item.
Requirements
- Versioning is at the level of data files.
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.
- When a new version of data file is deposited, a new identifier will be created.
- Adding or changing README files or metadata will not result in creation of a new identifier.
- 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.
- When a new identifier is created for a data file, a new identifier is automatically created for the corresponding data package.
- 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)
- Only the most recent version of an item is available via the search interface.
- On the item page, there is a link to view previous/subsequent versions.
- By examining the metadata
- , it is possible to determine whether an item is the most recent version, the original version, or an intermediate version.
- Previous versions of bitstreams are retained. If something was once retrievable, it is always retrievable.
- 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
- 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.
Scenarios | Description | New Data Package Version | New Data File Version |
Add Data File to Existing Data Package | Add a Data File Item to Dryad and add to existing Data Package | yes | yes |
Delete Data File from Package | Remove a Data File from an existing Data Package | yes | yes |
Replace Data File in existing Package | Remove an existing Data File (2) and add a new one (1) | yes | yes |
Edit Metadata in Data File | Metadata edits do not produce new Items | no | no |
Edit Metadata in Data Package | Metadata Edits do not produce new Items | no | no |
Metadata Mapping
General Versioning of DSpace Items
Generic Versioning of DSpace Items will involve the alteration of existing handles for those versions in DSpace.
= | =Version 1 | =Version 2 | =Version 3 |
dc.identifier.uri | 1234.5/1.1 | 1234.5/1.2 | 1234.5/1.3 |
dc.relation.isReplacedBy | 1234.5/1.2 | 1234.5/1.3 | |
dc.relation.replaces |
| 1234.5/1.1 | 1234.5/1.2 |
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)
| 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 |
| doi.10.561/dryad.154.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.
| File Version 1 | File Version 2 | File Version 3 |
dc.identifier | doi:10.651/dryad.154.1/1.1 | doi:10.561/dryad.154.2/1.2 | doi:10.561/dryad.154.3/1.3 |
dc.relation.isReplacedBy | doi:10.561/dryad.154.2/1.2 | doi:10.561/dryad.154.3/1.3 | |
dc.relation.replaces |
| doi.10.561/dryad.154.1/1.1 | doi:10.561/dryad.154.2/1.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:
Business Model
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.
Versioning an individual Bitstream on an Item
Versioning individual Bitstreams can be comparable to versioning attachements to a wiki.
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
from ArchiveManager (Possible methods for VersioningService)
Code Block |
---|
/**
* 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
Code Block | ||
---|---|---|
| ||
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
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.
- 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)
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
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...
Express Administrative Versioning Metadata in METS Administrative Section of
http://host/xmlui/metadata/handle/1234.5/102/mets.xml
Code Block | ||
---|---|---|
| ||
<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:terms="http://purl.org/dc/terms"
xmlns:myns="http://www.nsdl.org/ontologies/relationships#"
xmlns:oai_dc="http://www.openarchives.org/OAI/2.0/oai_dc/"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#">
<rdf:Description rdf:about="hdl:1234.5/100">
<dc:identifier>1.1</dc:identifier>
<dc:description>Summary of New Version</dc:description>
<dc:creator>mdiggory@gmail.com</creator>
<terms:created>2011-01-01::12:12:12Z...</terms:created>
<terms:isReplacedBy rdf:resource="hdl:1234.5/101"/>
</rdf:Description>
<rdf:Description rdf:about="hdl:1234.5/101">
<dc:description>Summary of New Version</dc:description>
<dc:creator>mdiggory@gmail.com</creator>
<terms:created>2011-01-01::12:12:12Z...</terms:created>
<dc:identifier>1.2</dc:identifier>
<terms:replaces rdf:resource="hdl:1234.5/100"/>
<terms:isReplacedBy rdf:resource="hdl:1234.5/102"/>
</rdf:Description>
<rdf:Description rdf:about="hdl:1234.5/102">
<dc:description>Summary of New Version</dc:description>
<dc:identifier>1.3</dc:identifier>
<dc:creator>mdiggory@gmail.com</creator>
<terms:created>2011-01-01::12:12:12Z...</terms:created>
<terms:replaces rdf:resource="hdl:1234.5/101"/>
<terms:isReplacedBy rdf:resource="hdl:1234.5/103"/>
</rdf:Description>
<rdf:Description rdf:about="hdl:1234.5/103">
<dc:identifier>1.4</dc:identifier>
<dc:description>Summary of New Version</dc:description>
<dc:creator>mdiggory@gmail.com</creator>
<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-isVersionOfhttp://dublincore.org/documents/2008/01/14/dcmi-terms/#terms-hasVersionhttp://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:
...
- 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
Administration
- Current Code Locations
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
- 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 (submission, deposit, import)
- Roles for which new versions should be possible (submitter, author, curator)
- Local User Submissions and Curator Reviews.
- Services that are effected by user scenarios
- SWORD v1 and v2 Version creation on Update
- LNI Version on Update
- Local ItemImport and Export Command-line services.
- Metadata Export and Import
- External Harvesters (OAI and DSpace)
- Further Requirements to Consider
- Deleting an Item from the Repository
- Moving and Item Between Collections
- 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.
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.
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
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
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.
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
RIS Representation
http://dev.datadryad.org/resource/doi:10.5061/dryad.r460n.2/citation/ris
Code Block |
---|
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
Code Block |
---|
@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}
} |