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.
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.
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)
Both the Advanced embargo and versioning proposals are specifically
designed to avoid this problem by using more explicit data relations,
versioning uses a versionhistory table and embargo conserves the existing
data model by extending and reusing resource policies.
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
<!--
Embargo metadata is intended to provide a machine-readable date on
which an embargo should be revisited;
the date field can be typed locally to provide an indication of
what should be done.
It is not intended that the machine date necessarily trigger an
access rights change without human intervention.
Checking and actioning embargo date information will need to be
implemented locally according to need.
-->
<embargo>
<human>Stanford only until 10 November 2012</human>
<machine>
<date type="release">2010-11-10</date>
</machine>
</embargo>
I can at least say that here... we are not reinventing the wheel...
However, I say we start from what we need in DSpace, get the details that
we need persisted, then talk about any future alignment in the larger
community (OR12?). Otherwise, this work could take years instead of months
to complete.
For instance, one current difference apparent is that Embargoed Access can
be specific to a group (release access to university affiliates on date)
and not public, so we need to be able to control the groups assigned to the
dated constrained embargo READ resource policy.
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
