On 04/08/2010 15:23, Sean Carte wrote: > On 3 August 2010 22:03, Richard Rodgers<rrodg...@mit.edu> wrote: > >> Hi Sean: >> >> See comments below - but I think you now have a correct understanding.. >> >> Thanks, >> >> Richard >> On Jul 26, 2010, at 10:23 AM, Sean Carte sean.ca...@gmail.com wrote: >> >> >>> On 26 July 2010 14:30, Hilton Gibson<hilton.gib...@gmail.com> wrote: >>> >>>> Hi Sean >>>> >>>> From what I understand the "lift-date" is calculated from the terms set. >>>> See: http://www.dspace.org/1_6_2Documentation/ch05.html#N13421 >>>> I think the terms can be input as 1 year, 6 months, 1 month from submit >>>> date. >>>> Maybe thats how it works. >>>> >>>> Cheers >>>> >>>> hg >>>> >>> 2010/7/26 Claudia Jürgen<claudia.juer...@ub.tu-dortmund.de>: >>> >>>> Hello, >>>> >>>> the default setter understands only a date string or the (configurable) >>>> term "forever". You can implement your own setter to use other terms, >>>> e.g. to calculate the lift date based on time spans, for more details >>>> see section: >>>> 5.2.17.2. Extending Embargo Functionality >>>> of the documentation. >>>> >>>> Hope that helps >>>> >>>> Claudia Jürgen >>>> >>> >>> Thanks Hilton and Claudia >>> >>> I had misunderstood the purpose of embargo.field.terms. >>> >>> So I should use this field to set the date on which I want the embargo >>> lifted, alternatively I could enter a duration in it? >>> >> Yes - whatever metadata field is configured for the terms is what the system >> looks at - but what *values* are permitted in that field depends on the >> 'setter' code being used. That is also configurable in dspace.cfg (property >> is plugin.....EmbargoSetter). The default setter >> (org.dspace.embargo.DefaultEmbargoSetter) >> understands only a literal date - and trivially copies it into whatever >> field is configured for the liftDate. If those fields are the same, it does >> exactly nothing. >> However, if you change the setter to >> org.dspace.embargo.DayTableEmbargoSetter, then you can enter a word or >> phrase that maps to a fixed number of days >> e..g "30 days" would cause the setter to assign the lift date to be 30 days >> after the item is installed. You configure your 'table of days' in >> dspace.cfg also >> (see documentation). >> >> If you need any other behavior, you will need to write a custom setter. I >> can certainly help/advise if needed. >> >> >>> And I should not use embargo.field.lift in my submission form as this >>> value gets calculated from what is entered into embargo.field.terms? >>> >> Correct don't use it - *unless* it happens to be the same as the terms field >> (in which case you really are using the terms field, it just happens to >> coincide) >> >>> So I suppose I could simply use this in my input form: >>> >>> <field> >>> <dc-schema>dc</dc-schema> >>> <dc-element>rights</dc-element> >>> <dc-qualifier></dc-qualifier> >>> <repeatable>false</repeatable> >>> <label>Embargo Lift Date</label> >>> <input-type>date</input-type> >>> <hint> If applicable, enter the date that the embargo can be >>> lifted.</hint> >>> <required></required> >>> </field> >>> >>> With this in dspace.cfg: >>> >>> embargo.field.terms = dc.rights >>> embargo.field.lift = dc.date >>> >> Yes, this is fine >> >>> >>> I suppose that's what this was trying to tell me: >>> " >>> 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. >>> " >>> >>> But then: >>> " >>> 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 reason, use two distinct fields instead. >>> " >>> >>> This seems to suggest I could have the following in dspace.cfg: >>> >>> embargo.field.terms = dc.rights >>> embargo.field.lift = dc.rights >>> >>> ... with only dc.rights in my input form? >>> >>> Does that sound about right? (From my testing it does seem to work.) >>> >> Yes, this is OK as well. The real question is whether you want to persist >> the terms over time: if you use a single field, then the terms will be >> obliterated >> once the lift date is calculated. That is, you won't (after the item is >> installed) be able to say 'this was a 6 month embargo', all you will see is >> the lift date. >> But if all you are entering are lift dates as terms, then it is somewhat >> wasteful to use 2 distinct metadata fields to hold the same value. >> Does this make sense? >> > Perfectly! > > Thanks Richard. > > Sean > Hi Richard
I have created a wiki page for user in South Africa. See: http://ir.sun.ac.za/wiki/index.php/Asset_Embargo Hope it helps. Cheers hg ------------------------------------------------------------------------------ The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm _______________________________________________ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
