Page History
| Table of Contents | ||||||
|---|---|---|---|---|---|---|
|
What is an Embargo?
An embargo is a temporary access restriction placed on metadata or bitstreams. Its scope or duration may vary, but the fact that it eventually expires is what distinguishes it from other content restrictions. For example, it is not unusual for content destined for DSpace to come with permanent restrictions on use or access based on license-driven or other IP-based requirements that limit access to institutionally affiliated users. Restrictions such as these are imposed and managed using standard administrative tools in DSpace, typically by attaching specific policies to Items, Collections, Bitstreams, etc. Embargo functionality was originally introduced as part of DSpace 1.6, enabling embargoes on the level of items that applied to all bitstreams included in the item. In DSpace 3.0, this functionality has been extended for the XML User Interface, enabling embargoes on the level of individual bitstreams.
DSpace 3.0 XMLUI Embargo Functionality
| Warning | ||
|---|---|---|
| ||
By enabling the DSpace 3.0 Embargo functionality you will break JSPUI submission functionality. JSPUI is not yet compatible with the new XMLUI Embargo. If you use JSPUI, please see the Pre-DSpace 3.0 Embargo section. |
Embargoes can be applied per item and per bitstream. The item level embargo will be the default for every bitstream, although it could be customized at bitstream level.
As a DSpace administrator, you can choose to integrate either Simple or Advanced dialog screens as part of the item submission process. These are outlined in detail in the sections Simple Embargo Settings and Advanced Embargo Settings.
...
On the level of an individual item, a new Private/Public state has been introducted to control the visibility of item metadata in the different indexes serving the DSpace web interface (search, browse, discovery), as well as machine interfaces (REST-API, OAI-PMH, ...…)
The following functionality has been added in DSpace 3.0:
...
- Edit Item
- Edit Bitstream
- Wildcard Policy Admin Tool
Configuring and using
...
Embargoes in DSpace 3.0
| Warning |
|---|
Introduction
| ||
By enabling the DSpace 3.0 Embargo functionality you will break JSPUI submission functionality. JSPUI is not yet compatible with the new XMLUI Embargo. If you use JSPUI, please see the Pre-DSpace 3.0 Embargo section. |
Introduction
The following sections describe The following sections describe the steps needed to configure and use the new Embargo functionality in DSpace 3.0.
Note: when the embargo will be set at item level or bitstream level a new ResourcePolicy will be added.
Note: the new embargo is not supported on JSPUIThis embargo functionality is implemented using DSpace's system for ResourcePolicies.
Database
As a first step, the following script needs to be executed to ensure that your DSpace database gets extended with 3 new fields, required by the new embargo.
Wiki Markup
For PostgreSQL databases, the executed commands are:
...
Pre-DSpace 3.0 Embargo Compatibility
...
The Pre-DSpace 3.0 embargo functionality (see below) has been modified to adjust the policies setter and lifter. These classes now also set the dates within the policy objects themselves in addition to setting the date in the item metadata.
| Anchor | ||||
|---|---|---|---|---|
|
Embargo model and life-cycle
...
DSpace embargoes utilize standard metadata fields to hold both the '"terms' " and the '"lift date'". Which fields you use are configurable, and no specific metadata element is dedicated or pre-defined for use in embargo. Rather, you specify exactly what field you want the embargo system to examine when it needs to find the terms or assign the lift date.
...
You replace the placeholder values with real metadata field names. If you only need the '"default' " embargo behavior - which essentially accepts only absolute dates as '"terms' ",
this is the only configuration required, except as noted below.
...
You are free to use existing metadata fields, or create new fields. If you choose the latter, you must understand that the embargo system does not create or configure these fields: i.e. you must follow all the standard documented procedures for actually creating them (i.e. adding them to the metadata registry, or to display templates, etc) - this does not happen automatically. Likewise, if you want the field for '"terms' " to appear in submission screens and workflows, you must follow the documented procedure for configurable submission (basically, this means adding the field to input-forms.xml). The flexibility of metadata configuration makes if easy for you to restrict embargoes to specific collections, since configurable submission can be defined per collection.
Key recommendations:
embargoes to specific collections, since configurable submission can be defined per collection.
Key recommendations:
- Use a local metadata schema. Breaking compliance with the standard Dublin Core in the default metadata registry can create a problem for the portability of data to/from of your repository.
- If using existing metadata fields, avoid any that are automatically managed by DSpace. For example, fields like '"date.issued' " or '"date.accessioned' " are normally automatically assigned, and thus must not be recruited for embargo use.
- Do not place the field for '"lift date' " in submission screens. This can potentially confuse submitters because they may feel that they can directly assign values to it. As noted in the life-cycle above, this is erroneous: the lift date gets assigned by the embargo system based on the terms. Any pre-existing value will be over-written. But see next recommendation for an exception.
- As the life-cycle discussion above makes clear, after the terms are applied, that field is no longer actionable in the embargo system. Conversely, the '"lift date' " field is not actionable until the application. Thus you may want to consider configuring both the '"terms' " and '"lift date' " to use the same metadata field. In this way,
during during workflow you would see only the terms, and after item installation, only the lift date. If you wish the metadata to retain the terms for any resaon, use 2 distinct fields instead.
...
After the fields defined for terms and lift date have been assigned in dspace.cfg, and created and configured wherever they will be used, you can begin to embargo items simply by entering data (dates, if using the default setter) in the terms field. They will automatically be embargoed as they exit workflow. For the embargo to be lifted on any item, however, a new administrative procedure must be added: the '"embargo lifter' " must be invoked on a regular basis. This task examines all embargoed items, and if their '"lift date' " has passed, it removes the access restrictions on the item. Good practice dictates automating this procedure using cron jobs or the like, rather than manually running it.
The lifter is available as a target of the 1.6 DSpace launcher - see launcher documentation for details.
...
The 1.6 embargo system supplies a default '"interpreter/imposition' " class (the '"Setter'") as well as a '"Lifter'", but they are fairly rudimentary in several respects.
...
The default setter recognizes only two expressions of terms: either a literal, non-relative date in the fixed format '"yyyy-mm-dd' " (known as ISO 8601), or a special string used for open-ended embargo (the default configured value for this is 'forever', but this can be changed in dspace.cfg to 'toujours', 'unendlich', etc). It will perform a minimal sanity check that the date is not in the past. Similarly, the default setter will only remove all read policies as noted above, rather than applying more nuanced rules (e.g allow access to certain IP groups, deny the rest). Fortunately, the setter class itself is configurable and you can 'plug in' any behavior you like, provided it is written in java and conforms to the setter interface. The dspace.cfg property:
...
Overview
Content Tools