[Archivesspace_Users_Group] Community review of Rights Management Enhancements specification

Fri Oct 7 09:19:59 EDT 2016

Thanks for bringing up the question of just *how *PREMIS might be used to
express rights, Maureen.  We here at the Bentley (OK...Max) shared some
thoughts on how/why PREMIS rights could be useful in conjunction with more
human-readable conditions governing access/use statements:

http://archival-integration.blogspot.com/2016/02/a-primer-on-premis-and-premis-rights.html

Cheers,

Mike

--
*Michael Shallcross, CA*
*Assistant Director for Curation*

Bentley Historical Library
1150 Beal Ave.
Ann Arbor, MI 48109-2113
734.936.1344
http://bentley.umich.edu/
@UmichBentley
http://archival-integration.blogspot.com/
@umbhlcuration

On Fri, Oct 7, 2016 at 8:48 AM, Maureen Callahan <mcallahan at smith.edu>
wrote:

> Hi Jordon,
>
> I guess it all depends on what you mean by both inheritance and
> machine-actionable. A rights statement will belong to a hierarchy in the
> same way that a higher-level scope and content note will -- it sits higher
> in the tree and we have all agreed that higher-level elements implicitly
> apply to lower-level elements. All of this data can be accessed through a
> number of means (the API, the GUI, the database) and you could set up
> systems so that machines can do actions with the data -- to look higher in
> the tree to see which rights statements apply. But ArchivesSpace itself
> won't do the work of associating a condition governing access or use (as
> expressed in rights, rather than access/use subrecords) with containers
> that are associated lower down in the hierarchy in a way that would let a
> system know whether or not a container should circulate. Here, I'm really
> strictly talking about associating machine-actionable restrictions with top
> containers. The granular restriction types and restriction begin/end dates
> in conditions governing access/use DO let you do this.
>
> It's an extremely rare occasion that I disagree with Hillel, but I do
> think that generally, it's important to remember that these systems are a
> way to make standards actionable and description manageable, but that even
> when systems go away, standards persist. My guess is that the folks who
> wrote this specification have very well-defined boundaries about the
> appropriate way to leverage PREMIS rights statements. I also think that
> this proposal is good, because PREMIS rights are meant to do different
> things than DACS conditions governing access or use statements, and there
> may be good use cases for linking this information across both
> ArchivesSpace and a digital preservation repository. But I'm also going to
> guess that not every archivist is familiar or comfortable with those
> distinctions, and it might be helpful to see an explanation of "As an
> archivist managing electronic records in a digital preservation repository,
> I want for the rights module to be in better alignment with PREMIS rights
> so that I may _______." Similarly, there's a lot baked into ArchivesSpace
> about how to write DACS-compliant description in ArchivesSpace, but I think
> that much goes unsaid there too.
>
> Thanks!
> MC
>
> On Thu, Oct 6, 2016 at 4:52 PM, Jordon Steele <jsteele at jhu.edu> wrote:
>
>> Thanks, everyone.
>>
>>
>>
>> Maureen, I was not aware that the Rights module would not follow the
>> principle of inheritance. Seems like it should, if the rights information
>> being assigned exists in context of a hierarchy.  Setting aside the
>> intricacies of what PREMIS or DACS set out to accomplish, any user would
>> logically look at a field in ASpace called “Rights Statements” and think,
>> “Oh, that’s where I put information about what people can and can’t do with
>> my stuff.”
>>
>>
>>
>> You also raise a good point that rights information may not map properly
>> to discovery tools like ArchiveGrid if entered in the Rights module. The
>> implication, then, is that those of us that want to manage our rights with
>> more granularity, and consolidate the locations where that rights
>> information exists, are left with some pretty serious trade-offs.
>>
>>
>>
>> I’ll say that I would be more comfortable managing my rights information
>> in the access/use notes coming from an archives/DACS tradition, but the big
>> weakness for us is that you can’t record atomic rights information in these
>> elements in the accessions module, and according to one offline response I
>> received access/use notes don’t transfer over when you spawn a resource
>> record (which sounds like a bug, can’t believe that was intentional, but I
>> digress).
>>
>>
>>
>> Here’s an idea: should we instead be focusing on moving some of the
>> rights statement functionality to access/use notes and sunsetting the
>> rights module altogether, rather than having parallel places to put the
>> same information?
>>
>>
>>
>> Which leads me to my main point. Hillel, I think you hit the nail on the
>> head: thanks to Max’s helpful replies I now realize that it is beyond the
>> scope of this project to consider how best to manage rights information in
>> ASpace; rather, this project is limited to making some informed
>> improvements to one place a user can manage rights information. So you guys
>> are off the hook! But what about the rest of us thinking about how this
>> bundle of features that add up to ASpace—are we missing a greater
>> opportunity here? I would argue that giving people more than one place to
>> put the same information is questionable product design, and now might be
>> good time to fix that. I think the argument that giving people options is a
>> collegial gesture, but I just don’t buy it.
>>
>>
>>
>> Best,
>>
>>
>>
>> Jordon
>>
>>
>>
>> Jordon Steele
>>
>> Hodson Curator of the University Archives
>>
>> The Sheridan Libraries
>>
>> Johns Hopkins University
>>
>> 3400 N Charles St
>>
>> Baltimore, MD 21218
>>
>> 410-516-5493
>>
>> jsteele at jhu.edu
>>
>>
>>
>> *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:
>> archivesspace_users_group-bounces at lyralists.lyrasis.org] *On Behalf Of *Arnold,
>> Hillel
>> *Sent:* Wednesday, October 05, 2016 5:51 PM
>>
>> *To:* Archivesspace Users Group <archivesspace_users_group at lyr
>> alists.lyrasis.org>
>> *Subject:* Re: [Archivesspace_Users_Group] Community review of Rights
>> Management Enhancements specification
>>
>>
>>
>> Hi all,
>>
>> I just wanted to jump in to thank all of you who’ve provided feedback on
>> the proposal thus far, and to encourage others to chime in. I also wanted
>> to echo Max’s point that this specification is really addressed at
>> machine-interoperability and improving compliance with community standards
>> (in this case PREMIS).
>>
>> While those of use who pulled together this specification have use cases
>> in mind, and concrete ways in which we intend to use the proposed
>> functionality, I don’t think any of us want to prescribe how data should be
>> recorded in the application for all institutions and all use cases. The
>> community may be able to agree on approaches to recording this data (and I
>> think that conversation is useful and worthwhile), but it seems well
>> outside of the scope of this proposal.
>>
>> I’d also like to point out that the three options for recording rights
>> information that Max laid out exist in the current version of the
>> application (and probably earlier versions as well). This specification
>> doesn’t change that; in essence all it proposes is to make those structured
>> rights statements PREMIS-compliant.
>>
>> In any event, let’s keep the feedback coming!
>>
>>
>>
>> Hillel
>>
>> -----------
>>
>> Hillel Arnold
>>
>> Assistant Director, Head of Digital Programs
>>
>> Rockefeller Archive Center
>>
>> 914.366.6382
>>
>>
>>
>> *From: *<archivesspace_users_group-bounces at lyralists.lyrasis.org> on
>> behalf of Maureen Callahan <mcallahan at smith.edu>
>> *Reply-To: *Archivesspace Users Group <archivesspace_users_group at lyr
>> alists.lyrasis.org>
>> *Date: *Wednesday, October 5, 2016 at 4:31 PM
>> *To: *Archivesspace Users Group <archivesspace_users_group at lyr
>> alists.lyrasis.org>
>> *Subject: *Re: [Archivesspace_Users_Group] Community review of Rights
>> Management Enhancements specification
>>
>>
>>
>> Dear Max and others,
>>
>>
>>
>> I'm so happy to see these proposed enhancements to the rights subrecord
>> to bring it in better alignment with PREMIS. This looks dope, and it looks
>> like it will make integration with digital preservation systems much easier.
>>
>>
>>
>> Thanks too for laying out the options for recording rights information,
>> Max. There are a couple of things that I would add from my perspective of
>> having worked on the requirements for enhanced conditions governing access
>> and conditions governing use notes that I would want folks to think about
>> before making description and usage decisions, especially since I know
>> there are a lot of new adopters of 1.5.x who may not have fully explored
>> this functionality.
>>
>>
>>
>> Looking at the underlying standards that govern a record in ArchivesSpace
>> is important, and part of the reason that we decided to work on conditions
>> governing access/use was because we were interested in using DACS guidance
>> for aggregated materials. Doing description outside of the content standard
>> -- rather, in lieu of the content standard used for all other records --
>> seems pretty iffy to me. If it were me, I would use DACS elements for
>> archival description and PREMIS elements for digital preservation
>> activities.
>>
>>
>>
>> As you say, the rights module will be very good for recording atomic
>> rights information on a PREMIS model. But if you're looking at an
>> aggregation of materials that may have children records, ArchivesSpace
>> won't know that the rights subrecord applies to the physical, lower-level
>> objects that circulate in boxes the same way that it knows about access/use
>> notes -- as is appropriate! I haven't yet seen a full articulation of the
>> difference between rights and conditions governing access/use, beyond what
>> we had created at Yale and Mary had circulated, but it seems like
>> conditions governing access/use are now very good with DACS principle 7, in
>> a way that there's no expectation for PREMIS rights statements to be.
>>
>>
>>
>> Indeed, the enhancements to access/use notes in 1.5.x use the archival
>> principles of inheritance in a way that the rights subrecord does not plan
>> to. In 1.5.x, if a series is marked as being available for research use in
>> 2027, ArchivesSpace knows that all of the top containers in that series are
>> not open until 2027. It won't know this about containers if rights
>> subrecords are used (because rights subrecords are based on PREMIS, which
>> is about electronic records -- although there's a role for aggregation in
>> describing electronic records too, of course).
>>
>>
>>
>> Finally, a big part of the migration from Archivists' Toolkit to
>> ArchivesSpace at Yale had to do with reconciling non-standard usage of AT.
>> There had been good reasons, I know, for using fields and records in
>> non-standard ways in AT at Yale, but the result was 80% of my time and 80%
>> of another colleague's time for six months (and thousands of dollars toward
>> contract programmers) to put the data back where it was expected so that it
>> could go into ArchivesSpace smoothly. You don't want to go through that if
>> you can avoid it. Plus, beyond the PUI, your EAD won't have the relevant
>> access/use information you need, which may be fine eventually but for now
>> won't work for inclusion in ArchiveGrid and a number of other projects that
>> rely on EAD.
>>
>>
>>
>> Since I'm away from Yale and this work now
>> <http://4.bp.blogspot.com/-hjyKJqD6Gz0/VEW1DU_xHzI/AAAAAAAAGFM/kjQLzEDFOOU/s1600/pullmebackin.gif>,
>> I'd love to hear what others who are using 1.5.x think about this.
>>
>>
>>
>> All best,
>>
>> Maureen
>>
>>
>>
>> On Wed, Oct 5, 2016 at 12:27 PM, Max Eckard <eckardm at umich.edu> wrote:
>>
>> Hi Jordon,
>>
>> The purpose of the community review just started is to surface pros and
>> cons and to adjust or augment the specification for a modification to the
>> Rights module in ArchivesSpace accordingly.
>>
>> The primary reasoning behind this specification is to support atomic and
>> thus machine-actionable rights statements in ArchivesSpace. However, these
>> statements, like you said, can also be used as descriptive elements, and
>> could display in ArchivesSpace public displays (in ArchivesSpace or in
>> other discovery systems). At the end of this process, if/when this
>> specification is implemented, users will have at least three basic options:
>>
>>    1. Use only Conditions Governing Access/Use notes.
>>    2. Use only the Rights module.
>>    3. Use the Conditions Governing Access/Use notes in conjunction with
>>    the Rights module in the way I described above or in some other way (the
>>    "we" I was referring to earlier was just the group of us that did some
>>    research and wrote up the rights module).
>>
>> This approach accommodates the various ways institutions already use and
>> want to use rights statements. Users recording rights data in the Rights
>> module should have the ability to publish (or not publish) to the PUI. I
>> talked with Brad briefly about this; sounds like it will need to be
>> reflected in the specification and the PUI group will need to be informed
>> to account for this change in its work. The specifics of that (what
>> displays, what doesn't, etc.) seem like they'd still need to be worked out.
>>
>> Finally, this enhancement work should not result in any data being lost.
>> While some current fields (like the ones you mentioned--these and others
>> are written out in the "Removals" section of the "Data Migrations" table)
>> are being transferred to others that support atomic statements. Actually,
>> the current Permissions/Restrictions field is a good case in point. The
>> migration scenarios provided in the specification indicate these changes
>> and what is to happen to current data, in this case being transferred to an
>> "Act" note with an appropriate label.
>>
>>
>>
>> Hope this helps and thanks again for the feedback!
>>
>> Max
>>
>>
>>
>> On Wed, Oct 5, 2016 at 9:35 AM, Jordon Steele <jsteele at jhu.edu> wrote:
>>
>> Thanks for your response, Max. When you say “we,” do you mean the
>> Technical Advisory Council? And please forgive my limited understanding
>> about the functions of the ASpace groups, but should the decision about the
>> pros and cons of integration and redundancy rest with the TAC or the User
>> Advisory Council—or Governance? My cursory understanding is that the UAC
>> advises the TAC on what feature enhancements the TAC should implement.
>> Maybe UAC and TAC have discussed this?
>>
>>
>>
>> To your point that the Rights module only should be used to manage
>> machine-actionable rights information, unless you plan to change something
>> in the enhancements, currently a user is not required to use the Rights
>> module only for this purpose—there are notes fields that one can use to put
>> rights statements that could easily live in access/use notes, too, and the
>> machine-actionable features are not required to create a rights record.
>>
>>
>>
>> Also, an important implication that one of my staff mentioned yesterday
>> is that it’s possible the public user interface development going on does
>> not account for institutions that choose to put their access/use
>> information in the rights module. Have there been discussions with the PUI
>> group about this?
>>
>>
>>
>> Speaking of granularity, I have a more granular request: your attachments
>> are useful, but it appears you have not provided a list of elements that
>> would be eliminated if these enhancements were adopted. For instance,
>> looking at your wireframes, it would appear that the free-text fields of
>> “permissions” and “restrictions” would go away. I don’t really have an
>> opinion right now on whether that’s a good idea or not, but it would be
>> helpful if you could provide us with a list of fields you’re proposing to
>> remove.
>>
>>
>>
>> Best,
>>
>>
>>
>> Jordon
>>
>>
>>
>> Jordon Steele
>>
>> Hodson Curator of the University Archives
>>
>> The Sheridan Libraries
>>
>> Johns Hopkins University
>>
>> 3400 N Charles St
>>
>> Baltimore, MD 21218
>>
>> 410-516-5493
>>
>> jsteele at jhu.edu
>>
>>
>>
>> *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:
>> archivesspace_users_group-bounces at lyralists.lyrasis.org] *On Behalf Of *Max
>> Eckard
>> *Sent:* Wednesday, October 05, 2016 9:08 AM
>> *To:* Archivesspace Users Group <archivesspace_users_group at lyr
>> alists.lyrasis.org>
>> *Subject:* Re: [Archivesspace_Users_Group] Community review of Rights
>> Management Enhancements specification
>>
>>
>>
>> Hi Jordan,
>>
>> Thanks for the feedback! This issue about the pairing of Conditions
>> Governing Access/Use notes and the Rights module has definitely come up in
>> our conversations.
>>
>> Borrowing some language from these conversations, at least for the moment
>> we see the statements in the ArchivesSpace Rights module being used in
>> conjunction with rights/access statements supported in the Conditions
>> Governing Access and Conditions Governing Use notes. The Rights module
>> statements are for granular, actionable statements, whereas the Conditions
>> Governing Access/Use notes are for summary, non-actionable statements, and
>> instructions, where appropriate, for contacting rights holders. That may
>> turn out to be an unnecessary redundancy, and clearly there are folks like
>> you that make a good case for that in theory and in practice, but that's at
>> least our thinking for now.
>>
>> Thanks again for your input! It really is very much appreciated!
>>
>> Max
>>
>>
>>
>> On Tue, Oct 4, 2016 at 11:59 AM, Jordon Steele <jsteele at jhu.edu> wrote:
>>
>> Max,
>>
>>
>>
>> These enhancements look good to us, thanks for your efforts.
>>
>>
>>
>> We’ve been discussing at JHU the overlap and, frankly, similarity between
>> what sort of information the Rights Management module is trying to capture
>> and the Conditions Governing Access/Use notes are used for, and we’re not
>> seeing a difference in concept between the two.  “Archivists have always
>> used the Access/Use notes” or “Access/Use notes are an EAD/DACS/AT
>> hold-over” may be factually accurate but they are not strong cases for
>> continuing use.
>>
>>
>>
>> So for the sake of not over-complicating the ASpace data model--where
>> equally valid locations for putting the same type of information
>> proliferate and, therefore, confuse—my main feedback is that you/the
>> community/whoever take a good look at integration between the access/use
>> notes and the rights management module. (After review of the responses I
>> received from the ASpace listserv and internal discussion, JHU has decide
>> to stop using the Access/Use notes and begin to use the Rights sub-records
>> to manage information about what people are allowed and not allowed to do
>> with all of our collections—analog and digital.) Your work presents a good
>> opportunity for us all to try to get on the same page.
>>
>>
>>
>> Best,
>>
>>
>>
>> Jordon
>>
>>
>>
>> Jordon Steele
>>
>> Hodson Curator of the University Archives
>>
>> The Sheridan Libraries
>>
>> Johns Hopkins University
>>
>> 3400 N Charles St
>>
>> Baltimore, MD 21218
>>
>> 410-516-5493
>>
>> jsteele at jhu.edu
>>
>>
>>
>> *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:
>> archivesspace_users_group-bounces at lyralists.lyrasis.org] *On Behalf Of *Max
>> Eckard
>> *Sent:* Monday, October 03, 2016 2:49 PM
>> *To:* Archivesspace Users Group <archivesspace_users_group at lyr
>> alists.lyrasis.org>
>> *Subject:* [Archivesspace_Users_Group] Community review of Rights
>> Management Enhancements specification
>>
>>
>>
>> Good morning ArchivesSpace community,
>>
>> You may already be aware that representatives from the ArchivesSpace
>> membership, the ArchivesSpace program team and Artefactual, Inc. have been
>> working on a specification for enhancing the rights module in
>> ArchivesSpace.
>>
>> The primary aim of this specification is to enable the expression of
>> standards-based rights statements that are atomic and actionable and that
>> support data transfers with other applications using rights statements,
>> such as Archivematica.
>>
>> We have completed a draft specification, and are now asking for community
>> review and feedback.
>>
>> The attached packet includes:
>>
>>    - a summary of the enhancements requested in the specification and
>>    their purpose;
>>    - a spreadsheet containing:
>>
>>
>>    - 1) the data model being proposed for the rights management module
>>       in ArchivesSpace,
>>       - 2) the data migrations necessary for moving data in the current
>>       data model to the new data model,
>>       - 3) a chart indicating the data elements to be migrated from
>>       Archivematica to ArchivesSpace, and
>>       - 4) a data map illustrating how PREMIS rights elements are
>>       supported in Archivematica and ArchivesSpace; and
>>
>>
>>    - ten wire frames illustrating how the proposed data model should be
>>    reflected in the ArchivesSpace staff interface.
>>
>> If you need some orientation to the way that PREMIS Rights Statements are
>> used (regardless of whether these are authored in ArchivesSpace), see the
>> attached PDF.
>>
>> Please take a look. Brad Westbrook (brad.westbrook at lyrasis.org), Hillel
>> Arnold (harnold at rockarch.org) and/or myself (eckardm at umich.edu) are
>> happy to answer any questions that you may have and to receive feedback on
>> the specification by *Friday, October 21, 2016*.
>>
>> Regards,
>>
>> Max Eckard
>>
>>
>> --
>>
>> *Max Eckard*
>> *Assistant Archivist for Digital Curation*
>>
>>
>>
>> Bentley Historical Library
>>
>> 1150 Beal Ave.
>> Ann Arbor, MI 48109-2113
>> (734) 763-7518
>>
>> http://bentley.umich.edu/
>>
>>
>> _______________________________________________
>> Archivesspace_Users_Group mailing list
>> Archivesspace_Users_Group at lyralists.lyrasis.org
>> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>>
>>
>>
>>
>> --
>>
>> *Max Eckard*
>> *Assistant Archivist for Digital Curation*
>>
>>
>>
>> Bentley Historical Library
>>
>> 1150 Beal Ave.
>> Ann Arbor, MI 48109-2113
>> (734) 763-7518
>>
>> http://bentley.umich.edu/
>>
>>
>> _______________________________________________
>> Archivesspace_Users_Group mailing list
>> Archivesspace_Users_Group at lyralists.lyrasis.org
>> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>>
>>
>>
>>
>> --
>>
>> *Max Eckard*
>> *Assistant Archivist for Digital Curation*
>>
>>
>>
>> Bentley Historical Library
>>
>> 1150 Beal Ave.
>> Ann Arbor, MI 48109-2113
>> (734) 763-7518
>>
>> http://bentley.umich.edu/
>>
>>
>> _______________________________________________
>> Archivesspace_Users_Group mailing list
>> Archivesspace_Users_Group at lyralists.lyrasis.org
>> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>>
>>
>>
>>
>>
>> --
>>
>> Maureen Callahan
>>
>> Sophia Smith Collection Archivist
>>
>> Smith College Special Collections
>>
>> Northampton, Massachusetts 01063
>>
>> T. 413 585 2981 C. 215.863.1860
>>
>> mcallahan at smith.edu
>>
>> _______________________________________________
>> Archivesspace_Users_Group mailing list
>> Archivesspace_Users_Group at lyralists.lyrasis.org
>> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>>
>>
>
>
> --
> Maureen Callahan
> Sophia Smith Collection Archivist
> Smith College Special Collections
> Northampton, Massachusetts 01063
> T. 413 585 2981 C. 215.863.1860
> mcallahan at smith.edu
>
> _______________________________________________
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group at lyralists.lyrasis.org
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161007/46846601/attachment.html>