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 substantially complicate a workflow that many seem to want to simplify: many admins find it a confusing model, let alone submitters.
However, I do think that you are right that a metadata approach (like the one proposed for the emabargo work) is a promising one to solve the problem Claudia raises: "to influence the policies during submission". 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 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). 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 the discussion can be more concrete.... Thanks, Richard On Mon, 2009-08-03 at 09:59 +0200, Andrea Bollini wrote: > Hi Richard, > I write primary to you as chair of the embargo functionality workgroup > for 1.6 > Claudia has recently added a jira issue, DS-267, > http://jira.dspace.org/jira/browse/DS-267 > about the opportunities to make modifiable during the submission process > 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 > > I think that we can easily archive this goal if we change the time when > 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 > during the WorkspaceItem creation so that we have the policies already > in place during the submission and we can manage them. > 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 > your solution only make an alternative way available. > In particular, if you are fine with moving the "inherit policies" from > 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 > classic open access rule. The type and numbers of "embargo options" are > configurable in the dspace.cfg on a collection basis. > Please add your comment on the jira system: DS-267, > best > Andrea > > PS: please note that for share our embargo solution with the community I > 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 > dspace API core change related to the time of resource policy definition > or at least we really want evaluate this change > ------------------------------------------------------------------------------ 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
