<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
Dear colleagues,<br class="">
<br class="">
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.
<div class=""><br class="">
</div>
<div class="">The stories around this action that we submitted to our excellent vendor are available here: <a href="https://docs.google.com/document/d/1Uf6x5_MVayxO3Pt53jYQJ1AwDGhEqw7GlDAxV4wEhH8/edit?usp=sharing" class="">https://docs.google.com/document/d/1Uf6x5_MVayxO3Pt53jYQJ1AwDGhEqw7GlDAxV4wEhH8/edit?usp=sharing</a> 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: <a href="https://github.com/hudmol/yale_containers" class="">https://github.com/hudmol/yale_containers</a> ).</div>
<div class=""><br class="">
</div>
<div class="">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.</div>
<div class=""><br class="">
</div>
<div class="">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!</div>
<div class=""><br class="">
</div>
<div class="">Best wishes,</div>
<div class="">Maureen</div>
<div class="">on behalf of the Yale ArchivesSpace implementation committee</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
Maureen Callahan<br class="">
Archivist, Metadata Specialist<br class="">
Manuscripts & Archives<br class="">
Yale University Library<br class="">
<a href="mailto:maureen.callahan@yale.edu" class="">maureen.callahan@yale.edu</a><br class="">
203.432.3627<br class="">
<br class="">
Webpage: web.library.yale.edu/mssa<br class="">
Collections: drs.library.yale.edu<br class="">
<br class="">
-----Original Message-----<br class="">
From: archivesspace@googlegroups.com [mailto:archivesspace@googlegroups.com] On Behalf Of Callahan, Maureen<br class="">
Sent: Thursday, February 19, 2015 7:41 PM<br class="">
To: archivesspace_users_group@lyralists.lyrasis.org; archivesspace@googlegroups.com; cmt@forums.archivists.org; description@forums.archivists.org<br class="">
Cc: Rush, Michael; Custer, Mark; Caldera, Mary; Chatalbash, Rachel; Wisner, Melissa<br class="">
Subject: [archivesspace] actionable restriction information<br class="">
<br class="">
Colleagues,<br class="">
<br class="">
We're looking for some thoughtful professional opinions before moving forward.<br class="">
<br class="">
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.<br class="">
<br class="">
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.<br class="">
<br class="">
In an ideal case, structured restriction information would let us do the following<br class="">
* 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<br class="">
* We would be able to run periodic reports about when restrictions are due to expire and change rights statements accordingly<br class="">
* 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)<br class="">
<br class="">
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.<br class="">
<br class="">
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?<br class="">
<br class="">
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?<br class="">
<br class="">
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?<br class="">
<br class="">
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.<br class="">
<br class="">
Warm wishes,<br class="">
<br class="">
Maureen Callahan<br class="">
on behalf of <br class="">
Mary Caldera, Mark Custer, and the Yale ASpace Committee<br class="">
<br class="">
Maureen Callahan<br class="">
Archivist, Metadata Specialist<br class="">
Manuscripts & Archives<br class="">
Yale University Library<br class="">
maureen.callahan@yale.edu<br class="">
203.432.3627<br class="">
<br class="">
Webpage: web.library.yale.edu/mssa<br class="">
Collections: drs.library.yale.edu<br class="">
<br class="">
-- <br class="">
You received this message because you are subscribed to the Google Groups "ArchivesSpace" group.<br class="">
To unsubscribe from this group and stop receiving emails from it, send an email to archivesspace+unsubscribe@googlegroups.com.<br class="">
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=
.<br class="">
</div>
</body>
</html>