A minor point..
On 5/17/2012 8:43 AM, Mark H. Wood wrote:
> On Wed, May 16, 2012 at 08:27:42PM +0000, Richard Rodgers wrote:
> [snip]
>> * 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').
>
> How hard could it be? We only need to preserve, in a machine-readable
> way, the fact that this policy was generated by an embargo requirement,
> and emit it as part of the AIP. [{View}, {forbidden}, {until date},
> {reason embargo}] should be readily interpretable by foreign systems
> having conforming DSpace AIP ingesters, if they implement such a concept.
>
> If we're not recording resource policies in AIPs now, we need to fix that.
We are recording resource policies in AIPs. They get translated into
METSRights Schema:
https://wiki.duraspace.org/display/DSDOC18/DSpace+AIP+Format#DSpaceAIPFormat-METSRightsSchema
This schema is used alongside a "DSPACE-ROLES" schema which is how we
translate our groups/epeople into AIPs.
Essentially, the goal of AIPs is to store *EVERYTHING* about the object
(Community/Collection/Item).
- Tim
------------------------------------------------------------------------------
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
