Developers,
At this point data ranges on Resource Policies work, but are not exposed in
the admin user interfaces for administrative users. Likewise, tools such
as ItemInstall, ItemImporter, EmbargoSetter, PolicySet and so on tend to
ignore or blow away these policy settings in favor of placing their own
policies in place when the Item is installed in the repository or released
from embargo.
@mire and University of Michigan Libraries are working on an Embargo
Contribution to DSpace that currently utilizes "Date Range" restricted
Resource Policies to enforce READ access for Embargo. This would include
adding editing interfaces on ResourcePolicies to support managing these
embargos.
1.) Date Ranges the Policy is in force.
2.) Description or Name of what the Policy is for
The intent is to transfer the definition of Embargo to these Policies
rather than having Item state such as embargo expressed in metadata. The
reason for this is
a.) that it makes enforcing Embargo on Bitstreams more granular/flexible,
Resource Policies can be used to directly enable Embargo.
b.) Make Embargo "stateless", ResourcePolicies do not get altered to
release embargo. The repository AuthorizationManager enforces the date
range intrinsically. The embargo resource policies can be left in place a
record of the embargo, even after the date is passed.
c.) Embargo can be managed in the Item Policy and Bitstream Policy Admin
UI.
d.) Finally, "retention limits", or a period the item should be available
can also be enforced before being restricted from access can also be
enforced.
The alternative to the above approach is that Embargo instead continue to
be enforced as alterations of the Resource Policies by a "agent"
(EmbargoLifter) and details concerning embargo that are used for these
state changes be encoded in the DSpace Item Metadata. To extend such a
system to have similar support for embargo control on individual
Bitstreams, we would need to either store similar metadata on Bitstreams,
or record which bitstreams are embargoed in a separate database table (the
Tapir Embargo model).
I'd like to measure the committer/developer groups opinion on this topic.
Please respond with your viewpoints. The most significant questions are:
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?
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.
Regards,
Mark Diggory
--
[image: @mire Inc.]
*Mark Diggory *(Schedule a Meeting <https://tungle.me/markdiggory>)
*2888 Loker Avenue East, Suite 305, Carlsbad, CA. 92010*
*Esperantolaan 4, Heverlee 3001, Belgium*
http://www.atmire.com
------------------------------------------------------------------------------
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
