[Archivesspace_Users_Group] follow up on actionable restriction information

[Callahan, Maureen]

Dear colleagues,

Many thanks for the outpouring of advice on restriction information in the last week. After reading all of your comments very carefully, we’ve found a path forward. In short, we decided that the simplest and most standards-compliant way will be to build out conditions governing access and conditions governing use subrecords so that they can support both date ranges and a configurable list of local restriction types (thereby supporting non-time-bound restrictions). We chose to go in this direction so that we wouldn’t interfere with work others may wish to do with rights subrecords, and so that development would have as small as possible an impact on existing use of the application.

The stories around this action that we submitted to our excellent vendor are available here: https://docs.google.com/document/d/1Uf6x5_MVayxO3Pt53jYQJ1AwDGhEqw7GlDAxV4wEhH8/edit?usp=sharing Please keep in mind that this is software development, and that all results will be the result of testing, compromise, and the art of the possible. Also keep in mind that parts of this functionality build on previous work (not yet released in full but available here: https://github.com/hudmol/yale_containers ).

There were a couple of questions about how this would affect EAD serialization, and my guess is that this will be an area where the community would have to come to consensus, since there isn’t yet a canonical way of structuring these kinds of attributes in <accessrestrict> or <userestrict>. We may decide to change the EAD export tool in our local implementation of ArchivesSpace, and we would of course be willing to share our work around that. We dream of a time in the future where our circulation system (Aeon) speaks directly to ArchivesSpace, at which time serialization of this data in EAD becomes less important.

Many thanks in particular to Meghan Lyon and her colleagues at Duke, Christie Peterson, Hillel Arnold, Meg Tuomala, Megan Mummey, and Esme Cowles. Your insights were all invaluable, and I’m planning to synthesize them into a blog post. We’ll also be sure to announce to the community once development on this feature has concluded. Stay tuned!

Best wishes,
Maureen
on behalf of the Yale ArchivesSpace implementation committee


Maureen Callahan
Archivist, Metadata Specialist
Manuscripts & Archives
Yale University Library
maureen.callahan at yale.edu<mailto:maureen.callahan at yale.edu>
203.432.3627

Webpage: web.library.yale.edu/mssa
Collections: drs.library.yale.edu

-----Original Message-----
From: archivesspace at googlegroups.com [mailto:archivesspace at googlegroups.com] On Behalf Of Callahan, Maureen
Sent: Thursday, February 19, 2015 7:41 PM
To: archivesspace_users_group at lyralists.lyrasis.org; archivesspace at googlegroups.com; cmt at forums.archivists.org; description at forums.archivists.org
Cc: Rush, Michael; Custer, Mark; Caldera, Mary; Chatalbash, Rachel; Wisner, Melissa
Subject: [archivesspace] actionable restriction information

Colleagues,

We're looking for some thoughtful professional opinions before moving forward.

As part of ArchivesSpace implementation, we at Yale are very interested in structuring information that has traditionally lived in Access Restriction and Use Restriction notes so that it can be machine-actionable for collection management and for circulation. For instance, perhaps a donor has stated that a series of materials is restricted until 2018. In our current practice, we would state this as clearly as possible in an access restriction note and go through the annual process of reporting on <accessrestrict> notes in finding aids to see if any restrictions have expired. Of course, this is a best case. In many cases, there's just too much data in these notes and we wait until we stumble across an expired restriction or a researcher brings it to our attention.

Beyond this, with our great bulk of materials, it's become important to know whether material in a container should be allowed to circulate. In Archivists' Toolkit, we extended the application to include a boolean checkbox of whether a box is restricted. This is suboptimal for many reasons, greatest of which is that a patron may be told that a container is restricted without any corresponding rationale related to the materials in the finding aid. We would like to improve upon this practice going forward.

In an ideal case, structured restriction information would let us do the following
* Our circulation system (Aeon) would be able to talk to our ArchivesSpace data (or a serialization of that data) and send restricted materials to their own work queue
* We would be able to run periodic reports about when restrictions are due to expire and change rights statements accordingly
* We would be able to associate information about rights to containers in the item records of our ILS (as is current practice at many repositories at Yale and is done asynchronously with description of restrictions in finding aids)

We were beyond thrilled to see the existence of Rights subrecords in ArchivesSpace, which do indeed have a place for structured date information parallel to a note. However, the Premis rights model (which I believe this is based on) and DACS/EAD don't approach rights in quite the same way. Before changing the EAD exporter and doing data remediation to get <accessrestrict> and <userestrict> into rights subrecords (which we are willing to do), we want to make sure that we're truly putting this data where it belongs.

A Rights subrecord can have one of four types -- administrative, intellectual property, license, statute. The first question that we have is whether a restriction on access (based on a deed of gift or transfer agreement) constitutes an administrative right. Some of us think so, others are less sure. What do you think?

Moving forward, if we were to agree that accessrestrict/userestrict information could go into rights subrecords, how would we handle the case where information that might have gone into userestrict ("Patrons may not take photographs of these records") and information that would have gone into accessrestrict ("In accordance with our deed of gift, these records may not be viewed until 2030"), would both be considered administrative rights? How would we serialize this in EAD without making a distinction elsewhere in the record ? And if we would need to modify the ArchivesSpace application, would it make more sense to modify it to add a date element to notes subrecords (also, obviously we're aware that EAD doesn't yet support date information for restrictions -- we would need a short-term hack and a long-term change proposal for EAD4)? And if this is the case, what is the use of Rights subrecords, anyway?

Your insight is valuable. Are machine-actionable restrictions important to you? How would you want them to be structured? Is an access restriction an administrative restriction? And finally, if you were to use a Yale-produced plug-in that created more structured rights information, what would be your concerns and priorities?

If you could respond very soon (within the next couple of days), we would appreciate it. We're on a fast march toward implementation deadlines.

Warm wishes,

Maureen Callahan
on behalf of
Mary Caldera, Mark Custer, and the Yale ASpace Committee

Maureen Callahan
Archivist, Metadata Specialist
Manuscripts & Archives
Yale University Library
maureen.callahan at yale.edu
203.432.3627

Webpage: web.library.yale.edu/mssa
Collections: drs.library.yale.edu

--
You received this message because you are subscribed to the Google Groups "ArchivesSpace" group.
To unsubscribe from this group and stop receiving emails from it, send an email to archivesspace+unsubscribe at googlegroups.com.
For more options, visit https://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com_d_optout&d=AwIFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=JgH2YCQ8D3P9-Lm_x4bv3d2CZBYlbx6hxnLFHtfovi8&m=acAFjJhtn4QXwJl0p-j07hHb4tFcZvxuA2pq2GpJAIM&s=42yHtv4w2cBtNSbXDW6Sg-p_cEwZwarG4Mzw9blfjSE&e= .
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20150304/05a1ebe7/attachment.html>