On Tue, May 22, 2012 at 6:45 AM, Mark H. Wood <[email protected]> wrote:
> On Mon, May 21, 2012 at 10:25:34PM -0700, Mark Diggory wrote:
> > On Mon, May 21, 2012 at 5:55 AM, Mark H. Wood <[email protected]> wrote:
> >
> > > On Fri, May 18, 2012 at 01:14:14PM -0700, Mark Diggory wrote:
> > > > >
> > > > > If the permission is
> > > > > a local policy then admin.s can alter it at will; but an embargo
> > > expresses
> > > > > some other organization's policy and can't be altered without
> > > > > negotiation. The AIP must express (machine-readably) *why* the
> policy
> > > > > is present, or we have lost important information.
> > > >
> > > >
> > > > Additionally, while I agree its the managers responsibility to
> negotiate
> > > > such external details, its impractical to try to engineer that level
> of
> > > > policy negotiation and description into DSpace itself. To be clear,
> when
> > > > working on code in DSpace, the first and foremost activity should be
> > > > engineering a content management system that is simple and works
> well.
> > > > Describing higher level policies an institution or third party may
> have
> > > > for embargo of an object are probably better served as additional
> > > attached
> > > > Bitstreams/Licenses or additional metadata in the Item record, not
> > > explicit
> > > > ResourcePolicies used for access control. This was not our goal in
> > > > extending them.
> > >
> > > So, I'm not seeing the place in the AIP from which we would recover
> > > the fact that a given resource policy was automatically generated from
> > > some other datum and *must not be manually altered*, at least not
> > > without a warning. I don't want DSpace to negotiate embargos; I just
> > > don't want it to forget what it did about them.
> > >
> > >
> > Firstly, the AIP serializes the ResourcePolicies (including those for the
> > embargo) as METS Rights clauses and when restoring, restores those
> clauses,
> > this is the best feature we have have for assuring the embargo is
> properly
> > maintained across restorations.
>
> Indeed, the rights get stored and recovered. But there is nothing in
> DSpace today which marks those rights as being related to an embargo,
> either internally or externally. Those rights are *a different kind
> of rights* than rights applied manually or from a manually-established
> default. We need to fix this, no matter how we represent the
> information externally.
>
This was the point of adding both a "name and description" to the
ResourcePolicy and possibly an additional type (or extensible typing, as
you suggested) so that we have a way to describe the resourcepolicy.
I didn't communicate very well -- I may not have fully realized --
> that we already have a problem: there is no way to know that we
> should pop up a "you do realize that you're about to violate a ${type}
> policy? are you sure?" message when someone thinks, "that's funny,
> what's it doing here?" and decides to remove a right which was created
> by, for example, the embargo machinery.
>
Depends on how you encode it... if the embargo is defined entirely in a
typed resourcepolicy with its own description, and you want to remove that
policy, its pretty clear your deleting the embargo policy. Not deleting a
generic READ policy that some "Agent" inserted on ItemInstall.
>
> > Secondly, the Embargo state is preserved in metadata and this is, as you
> > just pointed out, brittle for restoration. Without an explicit data model
> > for embargo, of course this application coded negotiation (recovery)
> > becomes subjective.
>
Thats exactly why we want to extend ResourcePolicy capabilities.
>
> I think it's more general than embargo, and I would caution against
> thinking solely in terms of embargo. We may find other reasons to
> have policies added automagically based on context. The essential
> characteristic here is that we have policies which are created by
> DSpace itself for reasons which are not apparent in the policies
> themselves, and which therefore should not be monkeyed with unless one
> has a thorough understanding of how they got there and why.
>
>
> Come to think of it, they shouldn't be manually manipulable at all; if
> one needs to e.g. alter an embargo interval then one should go through
> the embargo mechanism and let it calculate the changes. This would
> not only be safer, but also capture important information should we
> one day have a history mechanism once more.
>
If the "rules" for the embargo are properly encoded in the resource policy
and not the Item metadata, the setting the resource policy is the embargo
mechanism. Yes, special UI's could be designed around this if necessary.
The prototype already has them in ItemEdit and Submission for both the Item
and the Upload File steps.
>
> > There is a caution with storing the the embargo state in the metadata in
> > such a configurable manner, if there is a desire to change the configured
> > embargo fields, or restore the AIP across Repositories, then there is
> then
> > a need to makes sure there is the exact same embargo configuration on
> both
> > ends.
> >
> > This points out the fatal flaw in writing DSpace capabilities based on
> the
> > state of the metadata record and not some more explicit data structure
> and
> > persistance mechanism. (database tables or explicitly defined resource
> > policy objects)
>
> I think we're in violent agreement here. However DSpace becomes aware
> of the requirement for embargo, specific items will need to carry
> specific concrete instances of that requirement, and we could model
> those latter data better. Currently the system forgets why access is
> constrained. It contains, perhaps, enough data to infer the reason,
> but has no inference mechanism to do that, and we could just record
> the reason explicitly with much less effort and more certainty.
>
Sounds like we are in agreement the explicitly encoding embargo rules in
the ResourcePolicy is the way to go. and that those ResourcePolices are an
important part of the DSpace domain model and that the AIP needs to be
explicit about encoding them.
>
> > TBH, after reviewing the topic altogether (Premis, METSRights, so-on) My
> > opinion is that we should define our own explicit schema that meets our
> own
> > specific needs, then adapt as some future version of repository
> > interoperability emerges... For instance, we might engage the Hydra
> > community to see if we were to adopt the Hydra Rights model can we work
> > together to create an appropriate rights model that meets more Duraspace
> > wide needs
> >
> > https://wiki.duraspace.org/display/hydra/Hydra+rights+metadata
>
> I think that's a good idea. We might want to see what PRISM has in
> this area too, as there is other interest in PRISM support.
>
I think in either case, we are talking about
a.) an internal datamodel for embargo (ResourcePolicy) stored properly in
the database and nicely enforceable, and
b.) mappings to various external Disseminations for OAI,
Packagers/Crosswalks (METS, AIP, etc) for Allowing the dissemination and
backup of these policies.
c.) mappings to various external Ingesters for Packagers/Crosswalks (METS,
AIP, etc) for Allowing the setting of these policies.
both b and c have lots of room for play, we need agreement on (a) as a
final requirement before moving forward with any of b/c feature
requirements because it will inform those strategies.
Do we have agreement on (a)?
Mark
--
[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
