On Wed, May 16, 2012 at 1:27 PM, Richard Rodgers <[email protected]> wrote:
> Hi:
>
> Some very quick reactions to i. and ii. below:
>
> (i) as far as using RP date ranges as the *means* of enforcement for
> Embargo, it amounts to (an almost) minor implementation detail in the
> current design: an EmbargoSetter could easily write a start and end date in
> a policy,
> (instead of removing read policies as it now does). If the setter did
> this, then one would not need to run the Lifter agent at all.
>
Very very interesting to consider :-) Will look at it...
(ii) I'm not sure I understand the motivations well enough, but the aim of
> disallowing or replacing item metadata as the vehicle for embargo
> instructions seems like it raises several issues:
>
> * it means that all (or most all) programmatic ingest interfaces
> (SWORD, LNI, ItemImport, OAI harvest, etc) which do not, (and *should* not)
> know anything about the internals of the authorization system will be unable
> to convey embargo terms on ingest or deposit. That means that we have
> blocked any possibility of automatic ingest of embargo-able content, which
> is a big functional step backwards.
>
I think its a choice of how its represented in the package, I'm not
suggesting its shouldn't be in the manifest, the question is more, where
should it be in the manifest (premis Rights, so on). I don't think we
would immediately drop the availability of designating it in the metadata,
but the flexibly to make you own rules about which fields and what the
values should be sets the stage for certain amount of chaos in capturing
good generic SWORD submission usecases.
>
> * By making it an administrative function only (point 'd' below), it
> means that regular submitters who lack admin access cannot enter embargo
> instructions when submitting through the web UI, again complicating the
> process of embargo management. One could come up with special powers for
> submitters to just be able to set or alter a RP date, but this seems quite
> fragile/complex
>
The setting of Embargo via the UI would be by the Submission steps putting
in place the ResourcePolicies, either on the Item or on the Bitstreams
individually, recording the users reason in the description of the resource
policy. Later being able to be reviewed by the workflow Reviewers.
>
> * This effectively expands the data model for items to require policies.
> For example, when generating an AIP that can be restored to an embargoed
> state, we will need more than item metadata (i.e. resource policies data as
> well):
> this greatly limits data portability across systems - e.g. we cannot move
> content to a Fedora system while preserving embargo (without mapping to
> metadata on 'the way out').
>
But at this time, my understanding is that the ResourcePolicies are encoded
into AIP so that access control details can be recovered, and its the
format of these encodings I want to repurpose for encoding embargo details
into SWORD manifests and the like...
See for instance:
https://wiki.duraspace.org/display/DSDOC18/DSpace+AIP+Format#DSpaceAIPFormat-ExampleofMETSRightsSchemaforanItem
> I'll think more on this, however.
>
> Thanks,
> Richard
>
Excellent feedback, thank you Richard.
Best,
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
