On 3 August 2010 22:03, Richard Rodgers <[email protected]> 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 [email protected] wrote: > >> On 26 July 2010 14:30, Hilton Gibson <[email protected]> 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 <[email protected]>: >>> 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 -- Sean Carte esAL Library Systems Manager +27 72 898 8775 +27 31 373 2490 fax: 0866741254 http://esal.dut.ac.za/ ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-tech
