On Wed, May 16, 2012 at 11:48:55AM -0700, Mark Diggory wrote: [explanations] > i.) Should Date Ranges continue to be supported on DSpace Resource Policies > and be utilized for embargo purposes, or should they be abandoned and > activities such as embargo be enforced by having Agents "alter" Resource > Policies that should be in force for cases such as embargo?
Resource Policy date ranges +1 This simplifies the code and, I think, better models the process: the embargo interval is fixed at the moment of installation, and nothing about the item changes on the lift date, so we should just obey the policy and not alter any data. > ii.) Should Embargo "assertions" be stored in Item (and Bitstream) Metadata > Fields, or be recorded in a separate database table where embargo details > can be protected from view by users when the Item embargo requirements > include not showing any detail about the existence of the embargo (or the > Item/Bitstream it is on to public users. If we could set policies on metadata rows then the separate table is not needed. :-) May I suggest that a policy include a "type" attribute. I expect that the number of reasons for date-constrained policies will be small and that in the vast majority of cases the reason for a policy of a given type will be boilerplate. So there's a PolicyType table containing e.g. (7, "embargoed") and that takes care of describing the policy. We might have other reasons to mechanically distinguish classes of policies. -- Mark H. Wood, Lead System Programmer [email protected] Asking whether markets are efficient is like asking whether people are smart.
pgp1kFWUJEcNR.pgp
Description: PGP signature
------------------------------------------------------------------------------ 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
