Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3

Excerpt

The University of Michigan and @mire are initiating work to create a more robust and configurable embargo feature than the one that currently exists in DSpace.  We would like to invite others to tweak the feature set if there's additional features of interest.

https://jira.duraspace.org/browse/DS-895

Business Requirements

Without going into detail about the technical implementation, the basic feature set we are looking at, which will build on the current implementation includes the ability to provide

  1. Full embargo: no access to either the metadata or bitstream of an item until embargo period ends.  Items  Even if a match existsItems do not appear in: search or results, browse results, even if a match exists; though RSS feeds, OAI-PMH feeds, etc. Though the metadata and bitstreams are stored, it's as if the item and its bitstreams had never been deposited, or indexed.
  2. Partial embargo: metadata visible, some/all bitstreams inaccessible. In this case, items appear in browse or search indexes so searchers and browsers know an item and its bitstreams exist. However, they can't download/view bitstreams. (This is the behavior of the current implementation.)
  3. Group access to embargoed items: embargoed items (full or partial) are viewable and all contents are completely accessible to members of select groups.  This will address needs often expressed by archivists, who need a dark archive of materials in DSpace

...

Info

LCoNZ adds "Email based Embargo Termination Notification" and "Require Manual Embargo Release" business requirements to those already defined in general requirements.

Technical Requirements

Associated JIRA Tasks

Another LCoNZ addition is the distinction of permanent state vs temporary restrictions (where the expiry of a temporary restriction changes the item permissions to the underlying permanent state).

Technical Requirements

Associated JIRA Tasks

DS-908 Embargo DS-908 Embargo Overhaul: Utilize ResourcePolicy Start and Stop datestamps for enforcing embargo in DSpace

...

Restricting Discovery of Embargoed Items in Search and Browse

Tapir/IDEALS Solution:

Item will need to be restricted from search and browse, the Tapir solution for restricting Item from viewing in Search and Browse is to set Resource Policies inArchive=false on the Item that limit access to it, during the embargo period, an an "EmbargoLifter" command is responsible for removing these embargo settings fromt he and add it to a "restricted" table for access in the "Embargoed Item" Administrators View. An "EmbargoLifter" command is responsible for removing these embargo settings from the Item to lift the embargo

General Solution:

A possibility in the general approach will be not to add the item to a restricted table,, but continue to encode the embargo period and conditions in the ResourcePolicies and create a view over the Items based on this criteria (ideally by using Discovery to indicate that either the Item or one of its Bitstreams is embargoed)

Restricting viewing of Embargoed Items

...

The AuthorizationManager already supports the enforcement of timeframes in ResourcePolicies. I would like to propose that we expand ResourcePolicy in the following manner:I would like to propose that we expand ResourcePolicy in the following manner:

Encoding of Embargo Rights in AIP 

It should be possible to export and restore Embargo Rights on Bitstreams and Items based on PREMIS RIghts sections in the AIP

https://wiki.duraspace.org/display/DSDOC18/DSpace+AIP+Format#DSpaceAIPFormat-ExampleofMETSRightsSchemaforanItem

Migration from existing Embargo solutions

...

At the moment, only entire items can be embargoed, but the client is optionally interested in being able to set an embargo on the bitstream level as well. Optionally the client is requesting an implementation to support for current user to contact submitter for "request “request to access" access” the embargoed content.

Description

...

At this level the user can define general access settings options. This means that every new bitstream uploaded by default will have the same access settings defined by "Restrict Access" function.

  Image Removed   Image Added

*Note:*

1. *If the user will change the general access settings during the workflow or after the item is installed the new settings will be applied to all the bitstream(s) attached to the item.*
1. *If the general settings are "//Private/Closed Access"// won't be possible define custom settings at bitstream level.*

...

In the modules //UploadStep// and //EditItem// the user can define the custom access settings per bitstream, overriding the general defined previously.  Image Removed

   Image Added

Administrative Item Access

Image Added

To override the general settings the user must to check "//Enable Custom Settings//".

...

The first screenshot below shows the embargo screen where files can be fully embargoed only. The second screenshot shows a repository in which full/partial/no embargo can apply. The third screenshot shows permanent restriction settings.
Image Removed Image Added



Repository staff have access to a list of all embargoed items via an entry in the "Administrative" menu in the sidebar.

...