All Versions
- DSpace 7.x (Current Release)
- DSpace 8.x (Unreleased)
- DSpace 6.x (EOL)
- DSpace 5.x (EOL)
- More Versions...
Table of Contents | ||||||
---|---|---|---|---|---|---|
|
An embargo is a temporary access restriction placed on content, commencing at time of accession. It's 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 or Collections, Bitstreams, etc. The embargo functionally introduced in 1.6, however, includes tools to automate the imposition and removal of restrictions in managed timeframes.
...
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:
...
Expose the metadata field. Edit [dspace]/config/input-forms.xml
. If you have only one form‚ usually 'traditional', add it there. If you have multiple forms, add it only to the forms linked to collections for which embargo applies:
Code Block |
---|
<form name="traditional"> <page number="1"> ... <field> <dc-schema>dc</dc-schema> <dc-element>description</dc-element> <dc-qualifier>embargo</dc-qualifier> <repeatable>false</repeatable> <label>Embargo Date</label> <input-type>onebox</input-type> <hint>If required, enter date 'yyyy-mm-dd' when embargo expires or 'forever'.</hint> <required></required> </field> |
Note: if you want to require embargo terms for every item, put a phrase in the <required> element. Example: <required>You must enter an embargo date</required>
Configure Embargo. Edit [dspace]/config/dspace.cfg
. Find the Embargo properties and set these two:
Code Block |
---|
# DC metadata field to hold the user-supplied embargo terms embargo.field.terms = dc.description.embargo # DC metadata field to hold computed "lift date" of embargo embargo.field.lift = dc.description.embargo |
[dspace]/bin/dspace embargo-lifter
. You will want to run this task in a cron-scheduled or other repeating way. Item embargoes will be lifted as their dates pass.Expose the 'term' metadata field. The lift field will be assigned by the embargo system, so it should not be exposed directly. Edit [dspace]/config/input-forms.xml
. If you have only one form (usually 'traditional') add it there. If you have multiple forms, add it only to the form(s) linked to collection(s) for which embargo applies. First, add the new field to the 'form definition':
Code Block |
---|
<form name="traditional"> <page number="1"> ... <field> <dc-schema>dc</dc-schema> <dc-element>embargo</dc-element> <dc-qualifier>terms</dc-qualifier> <repeatable>false</repeatable> <label>Embargo Terms</label> <input-type value-pairs-name="embargo_terms">dropdown</input-type> <hint>If required, select embargo terms.</hint> <required></required> </field> |
Note: If you want to require embargo terms for every item, put a phrase in the <required> element, e.g. <required>You must select embargo terms</required>
Observe that we have referenced a new value-pair list: "embargo_terms'. We must now define that as well (only once even if referenced by multiple forms):
Code Block |
---|
<form-value-pairs> ... <value-pairs value-pairs-name="embargo_terms" dc-term="embargo.terms"> <pair> <displayed-value>90 days</displayed-value> <stored-value>90 days</stored-value> </pair> <pair> <displayed-value>6 months</displayed-value> <stored-value>6 months</stored-value> </pair> <pair> <displayed-value>1 year</displayed-value> <stored-value>1 year</stored-value> </pair> </value-pairs> |
Note: if desired, you could localize the language of the displayed value.
Configure Embargo. Edit [dspace]/config/dspace.cfg
. Find the Embargo properties and set the following properties (replace "local" with the name of your custom schema; you may need to create one if you don't already have it):
Code Block |
---|
# DC metadata field to hold the user-supplied embargo terms embargo.field.terms = dclocal.embargo.terms # DC metadata field to hold computed "lift date" of embargo embargo.field.lift = dclocal.embargo.lift # implementation of embargo setter plugin - replace with local implementation if applicable plugin.single.org.dspace.embargo.EmbargoSetter = org.dspace.embargo.DayTableEmbargoSetter |
Now add a new property called 'embargo.terms.days' as follows:
Code Block |
---|
# DC metadata field to hold computed "lift date" of embargo embargo.terms.days = 90 days:90, 6 months:180, 1 year:365 |
[dspace]/bin/dspace embargo-lifter
. ...