Hi:
Some very quick reactions to i. and ii. below:
(i) as far as using RP date ranges as the *means* of enforcement for Embargo,
it amounts to (an almost) minor implementation detail in the current design:
an EmbargoSetter could easily write a start and end date in a policy,
(instead of removing read policies as it now does). If the setter did this,
then one would not need to run the Lifter agent at all.
(ii) I'm not sure I understand the motivations well enough, but the aim of
disallowing or replacing item metadata as the vehicle for embargo instructions
seems like it raises several issues:
* it means that all (or most all) programmatic ingest interfaces (SWORD, LNI,
ItemImport, OAI harvest, etc) which do not, (and *should* not) know anything
about the internals of the authorization system will be unable
to convey embargo terms on ingest or deposit. That means that we have blocked
any possibility of automatic ingest of embargo-able content, which is a big
functional step backwards.
* By making it an administrative function only (point 'd' below), it means that
regular submitters who lack admin access cannot enter embargo instructions when
submitting through the web UI, again complicating the process of embargo
management. One could come up with special powers for submitters to just be
able to set or alter a RP date, but this seems quite fragile/complex
* This effectively expands the data model for items to require policies. For
example, when generating an AIP that can be restored to an embargoed state, we
will need more than item metadata (i.e. resource policies data as well):
this greatly limits data portability across systems - e.g. we cannot move
content to a Fedora system while preserving embargo (without mapping to
metadata on 'the way out').
I'll think more on this, however.
Thanks,
Richard
On May 16, 2012, at 2:48 PM, Mark Diggory wrote:
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
--
[@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<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]<mailto:[email protected]>
https://lists.sourceforge.net/lists/listinfo/dspace-devel
------------------------------------------------------------------------------
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
