[Archivesspace_Users_Group] Community review of Rights Management Enhancements specification

Jordon Steele jsteele at jhu.edu
Fri Oct 7 17:20:34 EDT 2016


Mike,

Thanks! The “Other Considerations” section is basically what I’m proposing. I am a PREMIS novice, but it strikes me as a superior solution for managing rights information than DACS notes, which is why the rights management module appeals to me.

But based on Maureen’s helpful warnings, I’m starting to doubt whether we’ll implement it, not really because of PREMIS or the rights module but because ASpace doesn’t seem to be designed well to use it in this (in my opnion, superior) manner. All the more reason to pump the breaks a bit and have a bigger conversation about how the rights statements and the access/use notes can be used in conjunction in a more direct way than just a human being knowing that this feature over here kinda relates to that feature over there.

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 Michael Shallcross
Sent: Friday, October 07, 2016 9:20 AM
To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org>
Subject: Re: [Archivesspace_Users_Group] Community review of Rights Management Enhancements specification

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
[https://webapps.lsa.umich.edu/dean/lsa_emails/bentley-sig-em.png]
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<mailto: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<mailto: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<tel:410-516-5493>
jsteele at jhu.edu<mailto:jsteele at jhu.edu>

From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto: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 lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.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<tel:914.366.6382>

From: <archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>> on behalf of Maureen Callahan <mcallahan at smith.edu<mailto:mcallahan at smith.edu>>
Reply-To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>>
Date: Wednesday, October 5, 2016 at 4:31 PM
To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.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<mailto: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<mailto: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<tel:410-516-5493>
jsteele at jhu.edu<mailto:jsteele at jhu.edu>

From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto: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 lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.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<mailto: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<tel:410-516-5493>
jsteele at jhu.edu<mailto:jsteele at jhu.edu>

From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto: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 lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.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<http://lyrasis.org>), Hillel Arnold (harnold at rockarch.org<http://rockarch.org>) and/or myself (eckardm at umich.edu<mailto: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

[https://webapps.lsa.umich.edu/dean/lsa_emails/bentley-sig-em.png]
Bentley Historical Library
1150 Beal Ave.
Ann Arbor, MI 48109-2113
(734) 763-7518<tel:%28734%29%20763-7518>
http://bentley.umich.edu/

_______________________________________________
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org>
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group



--
Max Eckard
Assistant Archivist for Digital Curation

[https://webapps.lsa.umich.edu/dean/lsa_emails/bentley-sig-em.png]
Bentley Historical Library
1150 Beal Ave.
Ann Arbor, MI 48109-2113
(734) 763-7518<tel:%28734%29%20763-7518>
http://bentley.umich.edu/

_______________________________________________
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org>
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group



--
Max Eckard
Assistant Archivist for Digital Curation

[https://webapps.lsa.umich.edu/dean/lsa_emails/bentley-sig-em.png]
Bentley Historical Library
1150 Beal Ave.
Ann Arbor, MI 48109-2113
(734) 763-7518<tel:%28734%29%20763-7518>
http://bentley.umich.edu/

_______________________________________________
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group at lyralists.lyrasis.org<mailto: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<tel:413%20585%202981> C. 215.863.1860<tel:215.863.1860>
mcallahan at smith.edu<mailto:mcallahan at smith.edu>

_______________________________________________
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group at lyralists.lyrasis.org<mailto: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<tel:413%20585%202981> C. 215.863.1860<tel:215.863.1860>
mcallahan at smith.edu<mailto:mcallahan at smith.edu>

_______________________________________________
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group at lyralists.lyrasis.org<mailto: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/8872dc71/attachment-0001.html>


More information about the Archivesspace_Users_Group mailing list