|
Ivan, Mark and Pascal,
I would like to take a moment to describe the forms of embargo that are supported (and possibly another that I have seen discussed in the community):
1.) Embargo Terms: The Submitter provides a "term" that describes the requirement for the embargo (a date range) and that term is used on archiving to set the Embargo lift date on archiving, this is done by the EmbargoSetter class (in pre 3.0 this was stored in metadata and all resource policies stripped off the Item Bitstreams, in post 3.0 this date is the start date of an anonymous resourcepolicy on either the Item or the Bitstream)
2.) Embargo Date: The Submitter provides an embargo date and this date is assigned as the lift date on the Item (in pre 3.0 this was stored in metadata and all resource policies stripped off the Item Bitstreams, in post 3.0 this date is the start date of an anonymous resourcepolicy on either the Item or the Bitstream)
3.) Blackout Period: In this case, an external system / user maintains the embargo rules and regulates when Items/Bitstreams may become publically available. Not only are Bitstreams access limited, but the entire Item should not be publically advertised until the terms described are met. Blackout has been implemented in three ways in the community:
(a) by keeping the item in a workflow stage that keeps it out of the archive until the publication blackout has been lifted. In this case, the Item cannot be discovered in search and browse and is only accessible to admins and those assigned to the blackout step.
(b) adding an embargo policy on the Item itself limiting is exposure to anonymous users in Search, Discovery and so on.
(c) making the item private or withdrawn, which strips all policies and removes the item from search/browse.
---------
The topic at OR15 emerged from a problem with OAI allowing the exposure of Items embargoed under 3.b. and 3.c. There was a desire expressed to be able to "exclude/include" Items from being visible in different services based on some model level criteria. In this case, Blackout Items (3.b. or 3.c.) should not be visible in OAI.
group:annonymous
action:read
item:123
application:OAI
Additionally, it was expressed that it would be ideal to be able to assign rights for interacting via specific applications to specific users/groups.
user:joe
action:write
item:123
application:SWORD
It was clear that we "do not want to duplicate" READ policies on Items for each application in question as that would be exhaustive and bloating. However, we may want to allow the admin to flag an Item as not to be visible in OAI via some resource policy on it. This suggests that policies may need to have a richer model than they currently have, either by the ability to add one or more applications to a resource policy, or by allowing "restriction" polices that can be assigned to restrict access to specific applications.
Restriction Policy (Embargo)
group:annonymous
action:restrict
start:2015-06-15
end: 2015-06-20
Read Policy
group:annonymous
action:read
start:null
end:null
Restriction Policy (Limit in OAI)
group:annonymous
action:restrict
item:123
application:OAI
This would allow flexibility for administrators to add policies as a means to include/exclude Items in specific applications, it would also allow for the clear specification of limitations in access (Embargo) separate from more general access terms.
HOWEVER, I always try to look to external authorities /dependencies on the topic of expressing ACL to assure we can align with those authorities, for example METS Rights, which we use heavily in AIP/SIP tooling, it is important to note that Rights are groups by a context
<rights:Context rpName="" in-effect="false" start-date="2014-01-01" CONTEXTCLASS="GENERAL PUBLIC">
<rights:Permissions DISCOVER="true" DISPLAY="true" MODIFY="false" DELETE="false" />
</rights:Context>
Currently Allowed "actions" are:
DISCOVER : Resource is available for searching or other discovery activities.
DISPLAY : Rendering, playing, executing the resource.
COPY : Making verbatim copy for purposes of re-use of whole or part of the resource and creation of new resource.
DUPLICATE : Make exact copy of resource for file or repository management purposes.
MODIFY : Annotate, edit, excerpt, embed, extract resource for purposes of re-use or preservation.
DELETE : Remove resource from repository for purposes of resource or repository management.
PRINT : Rendering the resource onto paper or hard copy.
OTHER : Allows for localized permission types
OTHERPERMITTYPE : Naming of localized permission types.
We try to leverage these for our policies that should be assigned when an Item in ingested via AIP. It is clear they were not intended to be "explicitly mapped" to ACL, but we try to do so as much as possible. Thus it is important to answer the question if the "Application of Access" and "Restriction" could possibly be captured in such a serialization as METS Rights before adding such capabilities.
Best,
Mark
|
