Re: [Dspace-devel] Alternative way to store embargo data

[Larry Stone]

The custom embargo plugin for my own site (I wrote the prototype implementation so I've had an advance look..) actually does something along these lines: It checks one DC metadata field for the embargo date, and another one for a condition that would place the item under "permanent embargo", so there are effectively two different metadata- driven access policy settings.

  -- Larry

On Aug 3, 2009, at 4:06 PM, Richard Rodgers wrote:

The major limitation in hijacking the embargo framework to do this job is that the embargo mechanism only calls the method that sets policies if the Item is actually deemed to be under embargo. You could simply declare all items to be under embargo to trigger the policy-setter, but that is counter-intuitive (especially if you also really use the embargo date to impose different policies for the embargo period). It might be very puzzling to anyone taking over the maintenance of your repository. On the other hand, if you do add a separate framework for fine-grained access control by metadata, then it has to be integrated with the embargo system so that when the embargo is lifted, the "default" policies are derived from the metadata as they would be in an embargo- less submission.

Hi Andrea:

I'm not clear about how such a proposed change would work: even if we
change the time of policy imposition to when the workspace item is
created, there is no way in the submission UI to manipulate them. To
bring over and expose the parts of the admin UI necessary to manage
policies on the submission side seems a bit daunting, and could

many admins find it a confusing model, let alone submitters.

However, I do think that you are right that a metadata approach (like

problem Claudia raises: "to influence the policies during submission".

interfaces, and you can add any logic you want behind them, you could
use the embargo framework to enforce item-specific access policies
entered at submit time that *don't* involve embargo (even
bitstream-level, if desired).


the discussion can be more concrete....

Thanks,

Richard

On Mon, 2009-08-03 at 09:59 +0200, Andrea Bollini wrote:

substantially complicate a workflow that many seem to want to simplify: the one proposed for the emabargo work) is a promising one to solve the In fact, that is precisely what the embargo framework does - it provides a means to express in metadata fields values that are *programmatically interpreted* at submission time to affect policies. Since these are just But maybe I have misunderstood what is being proposed, or the attendant complexity. I will post the current embargo code to the wiki shortly, so

Hi Richard,

for 1.6
Claudia has recently added a jira issue, DS-267,
http://jira.dspace.org/jira/browse/DS-267

the final permission applied to the item and its bitstreams.
As you can read from my comment:
http://jira.dspace.org/jira/browse/DS-267?focusedCommentId=10442&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_10442


the policies of the item/bitstreams are defined. At the moment, we
define the policy of the published item when them go in the archive
thought the InstallItem class that call the
inheritCollectionDefaultPolicies. I propose to make a similar call

in place during the submission and we can manage them.

your solution only make an alternative way available.

the archiving process to the start of submission, I will be able to
share with the community the CILEA solution for embargo (JSPUI only)
based on the first version of the work make by the Leiden University
http://wiki.dspace.org/index.php/Embargo_on_Bitstream_(JSP)
Our solution allows to define, independently for any bitstreams, an
access policy of anonymous read from a starting date, an restricted
access to one or more groups specificated in the dspace.cfg or a wide

configurable in the dspace.cfg on a collection basis.
Please add your comment on the jira system: DS-267,
best
Andrea


will need to perform some re-engineering to extract it from other our
customizations, so I like to perform them only if we agree with the

or at least we really want evaluate this change

I write primary to you as chair of the embargo functionality workgroup about the opportunities to make modifiable during the submission process I think that we can easily archive this goal if we change the time when during the WorkspaceItem creation so that we have the policies already I see that this solution partially overlaps with your assumption to use item metadata to store Embargo data but, IMHO my approach doesn't break In particular, if you are fine with moving the "inherit policies" from classic open access rule. The type and numbers of "embargo options" are PS: please note that for share our embargo solution with the community I dspace API core change related to the time of resource policy definition

------------------------------------------------------------------------------

what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Dspace-devel mailing list
Dspace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-devel

Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on

smime.p7s
Description: S/MIME cryptographic signature

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Dspace-devel mailing list
Dspace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-devel