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.
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.
> 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.
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.
> 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.
> 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.
--
Mark H. Wood, Lead System Programmer [email protected]
Asking whether markets are efficient is like asking whether people are smart.
pgpTVGUgqQoFn.pgp
Description: PGP signature
------------------------------------------------------------------------------ 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
