[
https://jira.duraspace.org/browse/DS-1175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=24898#comment-24898
]
Richard Rodgers commented on DS-1175:
-------------------------------------
Hi Richard:
Ah. that's an interesting case. As I said, the model assumes there is an
*algorithmic* relationship between the terms 'expression' and the lift date,
meaning that one can supply a function that turns the terms into a real date.
This function is guaranteed to be called exactly once at ItemInstall time, so
that, e.g. a 90 day clock only starts then, not while an item is languishing in
workflow. DSpace currently ships with 2 such 'functions', but of course you can
write your own custom Setter:
the default: really an 'identity' function (f(x) = x) - ie. the terms are just
the literal lift date as text
"day table": just a simple lookup table that maps a key to a number of days to
add to the install date (keys are like "90 days", "2 months", etc, but
user-configurable)
So in your case, the key question is whether there is any algorithmic
relationship between the 2 bits of metadata - i.e. can you derive the date from
the "on-site access only" stuff. Sounds like there isn't any such relationship,
so your options are:
(1) What you said above, put the date in the terms field (and just use the
default DSpace setter function), and stash the other data elsewhere.
(2) A bit more complex, but uses fewer fields: just write a custom setter that
trivially extends the default one to look for the date at the beginning or end
of the terms string, and concatenate the 2 bits together: "onsite only: lift on
12/31/2013" (i.e. that would be the terms string).
This version would use fewer metadata fields. It really depends on what you
want to store in metadata, and how it will be used....
Thanks,
Richard
> EmbargoManager looks for Embargo Lift Date in Embargo Terms
> -----------------------------------------------------------
>
> Key: DS-1175
> URL: https://jira.duraspace.org/browse/DS-1175
> Project: DSpace
> Issue Type: Bug
> Components: DSpace API
> Affects Versions: 1.8.2
> Environment: All
> Reporter: Richard Jones
> Priority: Major
> Labels: embargo
>
> The DSpace configuration defines two fields for use in Embargo:
> embargo.field.terms - for user-supplied terms of embargo
> embargo.field.lift - for the lift date of the embargo
> The EmbargoManager attempts to load the lift date of the embargo from the
> embargo.field.terms field, and does not check the embargo.field.lift. This
> then throws an error if no date is available in the embargo.field.terms.
> Looking deeper into this, there appears to be minimal usage of the
> embargo.field.lift field, and the documentation is confusing. Probably the
> fix is a rationalisation of what each of these fields actually means, and a
> re-implementation of at least the EmbargoManager and DefaultEmbargoSetter for
> consistency.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.duraspace.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Dspace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
