Controlling when a user can access a resource is an action a repository
provides in an automated fashion.
On Friday, May 18, 2012, Tim Donohue wrote:
> Hi Mark,
>
> I also thought about PREMIS Rights, but I'm not sure they are valid for
> what you are trying to do, as I believe they *only* deal with the rights of
> a repository to perform automated actions on an object.
>
> In PREMIS 2.1
> (http://www.loc.gov/standards/**premis/v2/premis-2-1.pdf<http://www.loc.gov/standards/premis/v2/premis-2-1.pdf>),
> you'll find the following statements about Rights info:
>
> Page 11-12: "The PREMIS rightsStatement is intended to allow a
> preservation repository to determine whether it has the right to perform a
> certain action in an automated fashion, with some documentation of the
> basis for the assertion."
>
> Page 31: "Rights: PREMIS primarily defines characteristics of rights and
> permissions concerned with preservation activities, not those associated
> with access and/or distribution. This revision broadens the semantic units
> used for rights information and allows for extensibility to use an external
> rights metadata scheme."
>
> In addition, the "termOfGrant" section is a sub-section of the
> "rightsGranted" section, which specifically states (page 195),
>
> rightsGranted: "The action(s) that the granting agency has allowed the
> repository."
>
> All of this leads me to believe that PREMIS Rights is referring to the
> Rights of the *repository* to perform actions on an object. However, what
> you are trying to describe is the access rights of *users* (and any embargo
> on those access rights). So, although PREMIS Rights may support embargo
> terms, I believe it's talking about an embargo on the rights of a
> repository -- and not an embargo on access rights of users.
>
> That's just my reading of PREMIS Rights. I could be wrong. But, that's why
> I chose to use METSRights schema (which is about user access rights)
> instead of PREMIS Rights within the AIPs.
>
> - Tim
>
>
> On 5/18/2012 10:05 AM, Mark Diggory wrote:
>
>> Review the following resources that outline some of the support...
>>
>> http://www.loc.gov/standards/**premis/v2/Rights-PREMIS-**
>> review-20120404.doc<http://www.loc.gov/standards/premis/v2/Rights-PREMIS-review-20120404.doc>
>>
>> http://www.dlib.org/dlib/**september08/dappert/09dappert.**html<http://www.dlib.org/dlib/september08/dappert/09dappert.html>
>>
>> http://metaarchive.org/imls/**index.php/Overview_of_PREMIS_**
>> Metadata_and_Recordkeeping_**for_ETDs<http://metaarchive.org/imls/index.php/Overview_of_PREMIS_Metadata_and_Recordkeeping_for_ETDs>
>>
>> *
>> o A number of early PREMIS adopters identified that the Rights
>> entity lacked the robustness required by various types of
>> digital objects such as ETDs. To address such limitations, the
>> PREMIS Editorial Committee has been working on changes and
>> enhancements to the Rights entity semantic units, for example to
>> allow for terms of restrictions (e.g., for embargo periods).
>> Currently there is just "term of grant", and "term of
>> restriction" is being proposed under the same container.
>> o
>>
>>
>> http://www.loc.gov/standards/**premis/v2/premis-2-0.pdf#**page164<http://www.loc.gov/standards/premis/v2/premis-2-0.pdf#page164>
>>
>> Specifically... Termofgrant.
>>
>> Mark
>>
>> On Friday, May 18, 2012, Tim Donohue wrote:
>>
>> I don't think the METSRights Schema is able to describe Embargos. Sure,
>> it can describe object permissions/access rights, but it doesn't have a
>> vocabulary to describe the starting/ending periods of the embargo (as
>> Mark Wood stated). When I chose to use the METSRights Schema for AIPs,
>> I
>> chose it specifically for its ability to translate DSpace Resource
>> Policies (which it can do quite well).
>>
>> So, we'd need to determine a different way to express embargoes so that
>> they can be fully restored. As Richard R mentioned earlier in this
>> thread, if we express the embargoes as *metadata* (in DC or in a
>> separate schema altogether, like an "ADMIN" schema), then they can be
>> stored in AIPs automatically and restored automatically (as AIPs
>> auto-store & restore all metadata associated with an Object). This is
>> how the current Embargo implementation works.
>>
>> If we feel storing embargo information as 'metadata' is insufficient,
>> then we will need to find a different way to translate them into the
>> AIPs. Off the top of my head, I'm not sure of a generic schema that is
>> geared towards describing embargoes. I just don't believe that
>> METSRights is what we are looking for.
>>
>> - Tim
>>
>> On 5/18/2012 7:34 AM, Mark H. Wood wrote:
>> > On Thu, May 17, 2012 at 04:36:04PM -0700, Mark Diggory wrote:
>> >> Tim,
>> >>
>> >> Given that you have experience with this, what do you think the
>> Rights
>> >> schema might look like for Embargo?
>> >>
>> >> <rights:RightsDeclarationMD xmlns:rights="
>> >>
>>
>> http://cosimo.stanford.edu/**sdr/metsrights/<http://cosimo.stanford.edu/sdr/metsrights/>
>> "<http://**cosimo.stanford.edu/sdr/**metsrights/<http://cosimo.stanford.edu/sdr/metsrights/>
>> >
>> >> RIGHTSCATEGORY="LICENSED">
>> >> <rights:Context CONTEXTCLASS="GENERAL PUBLIC">
>> >> <rights:Permissions DISCOVER="true" DISPLAY="true" MODIFY="false"
>> >> DELETE="false" />
>> >> </rights:Context>
>> >> </rights:RightsDeclarationMD>
>> >
>> > You addressed this to Tim, but if I may butt in: it has to be
>> > translated back to Embargo or we lose information. So the question
>> > that we need to answer is: how do we express embargo intervals
>> in METS?
>> >
>> >
>> >
>> >
>> >
>> ------------------------------**------------------------------**
>> ------------------
>> > 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/<http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/>
>> >
>> >
>> >
>> > ______________________________**_________________
>> > Dspace-devel mailing list
>> > [email protected] <javascript:;>
>> >
>> https://lists.sourceforge.net/**lists/listinfo/dspace-devel<https://lists.sourceforge.net/lists/listinfo/dspace-devel>
>>
>> ------------------------------**------------------------------**
>> ------------------
>> 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/<http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/>
>> ______________________________**_________________
>> Dspace-devel mailing list
>> [email protected] <javascript:;>
>>
>> https://lists.sourceforge.net/**lists/listinfo/dspace-devel<https://lists.sourceforge.net/lists/listinfo/dspace-devel>
>>
>>
>>
>> --
>> @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 <http://www.atmire.com/>
>>
>>
>>
--
[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
