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.unmigrated-wiki-markup
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>
unmigrated-wiki-markupConfigure
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').unmigrated-wiki-markup
- 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.unmigrated-wiki-markup
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.
unmigrated-wiki-markupConfigure
Embargo.
Edit
{{\
\[dspace
}}]/config/dspace.cfg
.
Find
the
Embargo
properties
and set the following propertiesand 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.unmigrated-wiki-markup
- 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.
Extending embargo functionality
...