Page History
Table of Contents | ||||||
---|---|---|---|---|---|---|
|
What is an embargo?
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:
- 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 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.
...
- Simple Dates.If you want to enter simple calendar dates for when an embargo will expire, follow these steps.
- Select a metadata field. For this example, let's use dclocal.description.embargo. This field does not exist in in the default DSpace metadata directory, so login as an administrator, go the metadata registry page, select (or create) the 'dclocal' schema, then add the metadata field.
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<schema>local</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 = dclocal.description.embargo # DC metadata field to hold computed "lift date" of embargo embargo.field.lift = dclocal.description.embargo
- Restart DSpace application. This will pick up these changes. Now just enter future dates (if applicable) in web submission and the items will be placed under embargo. You can enter years ('2020'), years and months ('2020-12'), or also days ('2020-12-15').
- Periodically run the lifter. Run the task:
[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.
- Period Sets.If you wish to use a fixed set of time periods (e.g. 90 days, 6 months or 1 year) as embargo terms, follow these steps, which involve using a custom 'setter'.
- Select two metadata fields. For this example, let's use 'dclocal.embargo.terms' and 'dclocal.embargo.lift'. These fields do not exist in the default DSpace metadata registry. Login as an administrator, go the metadata registry page, select (or create) the 'dclocal' schema, then add the metadata fields.
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
- Restart DSpace application. This will pick up these changes. Now the submitter can select a value form a drop-down list in web submission and the items will be placed under embargo.
- Periodically run the lifter. Run the task:
[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.
...