http://rucore.libraries.rutgers.edu/collab/ref/spc_sawg_r5_0_xacml.pdf
On Fri, May 18, 2012 at 11:08 AM, Mark Diggory <[email protected]> wrote:
> Looks like the trend on this in Fedora is XACML...
>
> Slide 26 of:
>
> http://dev.llgc.org.uk/wiki/images/6/67/DAMS%26DOMS_Presentation_to_LDAP.ppt
>
>
> http://rucore.libraries.rutgers.edu/collab/ref/spc_sawg_r5_1_xacml_embargo_utility.pdf
>
>
>
> On Fri, May 18, 2012 at 10:58 AM, Mark Diggory <[email protected]>wrote:
>
>> On Fri, May 18, 2012 at 9:04 AM, Tim Donohue <[email protected]>wrote:
>>
>>> Another thing I stumbled across...
>>>
>>> In the recent PREMIS 2.x tutorials [1], the slide about PREMIS Rights
>>> states:
>>>
>>> "Not a full rights expression language; focuses on permissions that take
>>> the form: Agent X grants Permission Y to the repository in regard to Object
>>> Z."
>>>
>>> Again, I think this implies that user access embargoes don't completely
>>> fit here. As I think they would require a permission statement like
>>> "Repository grants Permission Y to Agent X in regard to Object Z" (which is
>>> the complete opposite of what is stated above).
>>>
>>
>> In a way, this is what is being done when the deposit or submission is
>> made, the submitter is requesting the repository enforce a permission on
>> the repository.
>>
>>>
>>> However, stepping back, maybe it'd be possible to use METSRights +
>>> PREMIS Rights together. For example, METSRights could represent the current
>>> DSpace Resource Policies (as it already does), while PREMIS Rights could
>>> just hold the embargo timeperiod and state when the repository is first
>>> *allowed* to disseminate the object (based on whatever access rights are
>>> defined in METSRights). That *might* work. This is all just a brainstorm
>>> though...
>>>
>>> [1] PREMIS tutorial @ iPRES2011: http://www.loc.gov/standards/**
>>> premis/premis-tutorial_**iPRES2011_singapore.pdf<http://www.loc.gov/standards/premis/premis-tutorial_iPRES2011_singapore.pdf>
>>
>>
>> Personally, I think Reusing other folks schema is always a bit of a
>> pain... I'm personally unimpressed with most of the other METS standard
>> outside the ability to associate containers of information with files.
>> Thats why ORE emerged, TBH METS should have just been an aggregation model,
>> then get the hell out of the way...
>>
>> Right now, I'm just looking for
>>
>> 1.) Where to add Date Ranges to your existing ResourcePolicies encoded in
>> Rights.
>> 2.) Where to add any "Name" or "Description" encoded in the proposed new
>> ResourcePolicy fields that will describe the purpose of the ResourcePolicy.
>>
>> Semantic battles over how world thinks Embargo should be encoded in
>> PREMIS vs METSRights should be avoided. My need is to just add these
>> details to the AIP, I don't want to do whats right for the world, just for
>> DSpace AIP Marshalling/Unmarshalling ;-)
>>
>> It might be wise to review the Fedora or Hydra communities and see if
>> they passed through similar mine fields.
>>
>> Mark
>>
>>
>>>
>>> - Tim
>>>
>>>
>>> On 5/18/2012 10:42 AM, Tim Donohue wrote:
>>>
>>>> Mark,
>>>>
>>>> I still read it differently than you (and I don't know which reading is
>>>> "correct"). I've yet to find an example of someone using PREMIS Rights
>>>> to describe user access embargoes (if you know of one, forward it on).
>>>> Even the examples you provided in your initial email don't show any
>>>> examples of showing access related information in PREMIS Rights.
>>>>
>>>> For example in
>>>> http://www.dlib.org/dlib/**september08/dappert/09dappert.**html<http://www.dlib.org/dlib/september08/dappert/09dappert.html>they
>>>> state
>>>> they are storing access rights in *MODS*.
>>>>
>>>> My whole point is that I don't want DSpace to accidentally misuse PREMIS
>>>> Rights, as then our AIPs become less "useful" (i.e. it's less likely
>>>> that other systems can import them later on). Perhaps this is a question
>>>> that needs to be brought to the PREMIS creators themselves, if we cannot
>>>> find other examples to work from.
>>>>
>>>> - Tim
>>>>
>>>> On Friday, May 18, 2012 10:22:29 AM, Mark Diggory wrote:
>>>>
>>>>> 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>
>>>>> <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.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://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>
>>>>>
>>>>> <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>
>>>>> <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/>
>>>>> >"<http://__cos**imo.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/>
>>>>> <http://www.accelacomm.com/**jaw/sfrnl04242012/114/**50122263/<http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/>
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> > ______________________________**___________________
>>>>> > Dspace-devel mailing list
>>>>> > Dspace-devel@lists.**sourceforge.net<[email protected]><javascript:;>
>>>>> > https://lists.sourceforge.net/**__lists/listinfo/dspace-devel<https://lists.sourceforge.net/__lists/listinfo/dspace-devel>
>>>>> <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/>
>>>>> <http://www.accelacomm.com/**jaw/sfrnl04242012/114/**50122263/<http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/>
>>>>> >
>>>>> ______________________________**___________________
>>>>> Dspace-devel mailing list
>>>>> Dspace-devel@lists.**sourceforge.net<[email protected]><javascript:;>
>>>>> https://lists.sourceforge.net/**__lists/listinfo/dspace-devel<https://lists.sourceforge.net/__lists/listinfo/dspace-devel>
>>>>> <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__ <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/>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> @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
>>
>>
>>
>
>
> --
> [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
>
>
>
--
[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
