>
> 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.
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
