SUNScholar/Embargo Systems

From Libopedia
Revision as of 10:54, 15 August 2010 by Bibboek (talk | contribs) (1 revision)
Jump to navigation Jump to search

Introduction

In other words there are two methods of setting an embargo. You can specify fixed periods from the date of submission or you can specifiy a custom lift date. We choose the custom lift date method. There is something strange going on with the fixed period java code.

DSpace config settings

The following are our DSpace config settings.

#### Embargo Settings ####
# DC metadata field to hold the user-supplied embargo terms
embargo.field.terms = dc.embargo.terms
# DC metadata field to hold computed "lift date" of embargo
embargo.field.lift = dc.embargo.lift
# string in terms field to indicate indefinite embargo
embargo.terms.open = forever
# implementation of embargo setter plugin - replace with local implementation if applicable
plugin.single.org.dspace.embargo.EmbargoSetter = org.dspace.embargo.DefaultEmbargoSetter
# DC metadata field to hold computed "lift date" of embargo
#embargo.terms.days = None:0, 6 months:180, 1 year:365, 18 months:545, 2 years:730
# implementation of embargo lifter plugin - - replace with local implementation if applicable
plugin.single.org.dspace.embargo.EmbargoLifter = org.dspace.embargo.DefaultEmbargoLifter

Extra DSpace metadata fields

We added the following dc fields:

dc.embargo.terms
dc.embargo.lift

Modified input form

We modified the input.xml file in the source DSpace config folder:

<!-- The embargo terms input. Added by H Hgibson -->
	<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>onebox</input-type>
         <hint>If required, enter date in 'yyyy-mm-dd' format when the embargo expires or 'forever' if not.</hint>
         <required></required>
         </field>

So from the terms, the lift date is calculated by the embargo setter. But the terms and the lift date are the same using the custom method. This would not be true with the fixed period method. That is the reason for the confusion. We also tried the fixed period method and also added the following to the input.xml file.

<!-- Embargo terms for dropdown input. Added by H Gibson -->
	<value-pairs value-pairs-name="embargo_terms" dc-term="embargo.terms">
     <pair>
       <displayed-value>None</displayed-value>
       <stored-value>None</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>
     <pair>
       <displayed-value>18 months</displayed-value>
       <stored-value>18 months</stored-value>
     </pair>
     <pair>
       <displayed-value>2 years</displayed-value>
       <stored-value>2 years</stored-value>
     </pair>
   </value-pairs>

   <value-pairs value-pairs-name="absolute_valueUnit" dc-term="type">
     <pair>
       <displayed-value>Percentage</displayed-value>
       <stored-value>Percentage</stored-value>
     </pair>
   </value-pairs>

They match the terms in #embargo.terms.days = None:0, 6 months:180, 1 year:365, 18 months:545, 2 years:730 in the DSpace config file.

Daily cron job

You must run the embargo lifter task periodically to check for Items with expired embargoes and lift them. It is a command-line application invoked with the command:

 /home/dspace/bin/dspace embargo-lifter

Run it with the --help option to get a list of options.