Page History

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:

1. 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.
2. 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.
3. 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.
4. 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.

...

1. Simple Dates.If you want to enter simple calendar dates for when an embargo will expire, follow these steps.
   
   1. 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

   2. 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-markup

   3. 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

   4. 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
   5. 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.
2. 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'.
   
   1. 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

   2. 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-markup

   3. Configure

      Embargo.

      Edit

      {{\

      [dspace

      \

      ]/config/dspace.cfg

      }}

      .

      Find

      the

      Embargo

      properties

      and set the following 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

   4. 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

   5. 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
   6. 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

...