Making parent restrictions more evident

[Olivia S Solis]

Hello all,

I would like to file a JIRA request, but I am not entirely sure the best solution to an issue we have. The problem: If you are in a restricted archival object that has inherited a restriction from a parent via a Conditions Governing Access note, you have to do a lot of guesswork to locate the parent with the restriction. That restriction may be in a resource record or parent archival object, via a local access restriction or restriction dates.

This sometimes makes it difficult to remove/edit a restriction because the parent with the restriction may be difficult to locate. You also may not understand when you are editing/viewing at an AO with a restriction.

I am thinking that within a child AO with an inherited/indirect restriction, some kind of link similar to linked accessions or linked agents may work. However, those are subrecords that you manually add or in some cases are spawned. So it is a little different. This link would be dynamically updated or removed.

The other analog is the text that says if you click publish within an AO, that a parent is unpublished. But that text is not a link.

Another complicating factor is that there may be multiple restricted parents with increasingly restrictive restrictions. In this case, I think you just link to the one that the restriction is immediately inherited from.

Does anyone else have this problem or can think of the ideal behavior? I can file a ticket request without a specific solution proposed, but I'd prefer to at least suggest ideal behavior.

Thanks!

Olivia

--

Olivia Solis, MSIS (she/her)

Metadata Coordinator

Dolph Briscoe Center for American History

The University of Texas at Austin

2300 Red River St. Stop D1100

Austin TX, 78712-1426

(512) 232-8013

[Paul Sutherland]

Hi Olivia,

Thanks for raising this. We're about to do an overhaul of how some of our restrictions are displayed, and are also switching to the AS PUI, so this is timely for us.

I like the idea of a link.

On the PUI side, maybe this could be incorporated into the PUI inheritance. In this example, inherited fields from two different parents (a Collection and a Series) show. The text "From the Collection:" could become a link. Currently Conditions Governing Access notes do not display in this form in the PUI - they do not mention the source - but that could be brought in line with how these other notes show inheritance.

On the staff side, perhaps the link could be placed in this help text similar to the Publish help text. Both could have links from the word "ancestor" to be taken to the parent that causes this help text to appear. E.g.:

However, it's a bit tricky having these two places to flag restrictions ("Restrictions Apply" checkbox and "Conditions Governing Access/Use" notes). It always strikes me as a bit weird that these are so separate in the record. I figure the checkbox should not be automatically turned when a "Conditions Governing Access/Use" note exists, because DACS recommends having this note always present even to indicate an open resource/object. Maybe the help text here could clarify the specific source also of the restrictions (e.g. "This record has an ancestor with restrictions in the Conditions Governing Access note"). Or perhaps I'm overthinking this bit. Once at the record, staff can work out where to look.

Best,

Paul

--
You received this message because you are subscribed to the Google Groups "Archivesspace_Users_Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to Archivesspace_User...@lyrasislists.org.
To view this discussion on the web visit https://groups.google.com/a/lyrasislists.org/d/msgid/Archivesspace_Users_Group/CAKu%2Bi%3D1GaHHXJy%2BC12K4_uz8VrT_kAUJYxtoQ%2B8USP0Rg3ZGVg%40mail.gmail.com.

--

Paul Sutherland (he/his)
Archivist of Indigenous Materials
Center for Native American and Indigenous Research

Library & Museum
American Philosophical Society
105 S. 5th Street, 2nd Floor
Philadelphia, PA 19406

Lenapehoking

215-440-3408

amphilsoc.org/library/CNAIR

cn...@amphilsoc.org

CNAIR is hiring! CNAIR Reference Archivist, deadline March 4th.

I respectfully acknowledge that I work and reside in Lenapehoking, the homeland of the Lenape people in past, present, and future generations. I ​am grateful for the past and ongoing generosity of numerous Indigenous communities and individuals who have offered guidance, expertise, and opportunities for collaboration that make my work possible.

Learn more about ...

- The Indigenous Subject Guide to our Indigenous collections, updated frequently
- Blog posts by CNAIR staff & fellows
- Fellowships (residential and non) for working with our collections and elsewhere. Accepting applications now!
- Scheduling a visit to our Reading Room to view our collections
- Our museum is currently closed to prepare for the exhibit Sketching Splendor: Natural History in America, 1750-1850, opening later in 2024

[Dan Michelson]

Hi Olivia and Paul,

Many notes and subrecords, including Conditions Governing Access notes can be configured to be inheritable or not in the PUI by editing the yml file, that's what we've done here at Smith.  I highly recommend customizing this to fit your needs if you use the PUI, it's very easy.

All the best,

Dan

To view this discussion on the web visit https://groups.google.com/a/lyrasislists.org/d/msgid/Archivesspace_Users_Group/CAMqxH-oLUYHxT6YxfgKpj40rLtQMcte-zB2T5Ndtmv2qsVkyuA%40mail.gmail.com.

--

Dan Michelson

Collections Archivist

Smith College Special Collections

[Olivia S Solis]

Hi Dan and Paul,

Thanks for your feedback. Dan, I actually very much appreciate the restrictions being inherited. It is far more efficient and thorough than individually editing hundreds of child records that are necessarily restricted if the parent is. A processor might miss an archival object when unrestricting something, and it exponentially increases the work if restrictions aren't inherited. It also triggers a lot of smart behavior in the application process writ large. Really the only drawback for us is it's hard to locate the parent with the restriction.

Paul, it's funny you should mention that checkbox. We are re-evaluating our restriction policy. We just retired our use of restrictions apply? across the board. I did a breakdown of how each manifests in ASpace both in the PUI and SUI to recommend we ditch the checkbox. These were my arguments — note when something is restricted, we always use local access restrictions:

Pros 

• The Briscoe Center's use of Restrictions Apply? is inconsistent. 

• It is bad metadata practice to document the same or similar information in different fields. 

• It invites versioning conflicts that need to be individually re-investigated. 

• In the case of conflicts, users will not know which is accurate or may only view the inaccurate field. 

• It is likely that processors removing a local access restriction will not uncheck each Restrictions Apply? box for children AOs. 

• Restrictions Apply? gives no sense of what a restriction is. 

• The checkbox is significantly more work to apply and maintain. 

• Local Access Restrictions are far more visible and searchable in both the public and staff user interfaces. 

• The software itself favors Local Access Restrictions.  

• They are the mechanism used to flag boxes as restricted in Manage Top Containers. 

• They are used in the currently staff-only Restricted badge in the PUI. 

• Local Access Restrictions force processors to publicly indicate why something is restricted.  

• You cannot add them without a Conditions Governing Access note, where the Center has developed standardized language for specific restrictions. 

• The checkbox has no relevance to public users. 

Cons 

• It can be difficult to locate parent Local Access Restrictions from the staff interface. 

• It is difficult to query for children of restricted objects and cannot using the current database version

So Paul, while I like that text up high in the AO, it doesn't actually directly relate to the field that at least we are using to trigger restrictions. Unless, crazy thought, the application could automatically check that box for children of parents with machine actionable restrictions. I say this as a non-programmer.

Thanks,

Olivia

[Mary Mellon]

Hi all,

 

We have access restriction inheritance through our ArcLight PUI, which includes visual cues that contents are restricted. The main downside to this is that sometimes restrictions only apply to a portion of a unit (which is permitted per DACS 4.1.5), but all children will be flagged as restricted, which can be confusing to staff and researchers. I like Paul’s suggestion about including text to make clear that the restriction is inherited and from where, which could help head off this kind of issue. I also think it would be great to have better indicators of the presence of restrictions in the staff interface (maybe a visual cue in the archival object list, similar to the “suppressed” label, but maybe without the inheritance so you can see the specific AOs at which the notes are supplied?). Right now if I need to eyeball all the restrictions at once, I just export a bulk update spreadsheet that includes description levels and access notes (also handy for supplying those missing local access restriction types 😉 ).

 

Best,

 

Mary

 

Mary Mellon (she/her)

Metadata Archivist

Rubenstein Rare Book and Manuscript Library

Duke University

mary....@duke.edu

 

 

 

From: archivesspac...@lyrasislists.org <archivesspac...@lyrasislists.org> On Behalf Of Olivia S Solis
Sent: Thursday, February 22, 2024 10:08 AM
To: Dan Michelson <dmich...@smith.edu>
Cc: Paul Sutherland <psuth...@amphilsoc.org>; Archivesspac...@lyrasislists.org
Subject: Re: [External] [ArchivesSpace Users Group] Making parent restrictions more evident

 

Hi Dan and Paul,

 

Thanks for your feedback. Dan, I actually very much appreciate the restrictions being inherited. It is far more efficient and thorough than individually editing hundreds of child records that are necessarily restricted if the parent is. A processor might miss an archival object when unrestricting something, and it exponentially increases the work if restrictions aren't inherited. It also triggers a lot of smart behavior in the application process writ large. Really the only drawback for us is it's hard to locate the parent with the restriction.

 

Paul, it's funny you should mention that checkbox. We are re-evaluating our restriction policy. We just retired our use of restrictions apply? across the board. I did a breakdown of how each manifests in ASpace both in the PUI and SUI to recommend we ditch the checkbox. These were my arguments — note when something is restricted, we always use local access restrictions:

 

Pros 

·         The Briscoe Center's use of Restrictions Apply? is inconsistent. 

·         It is bad metadata practice to document the same or similar information in different fields. 

o    It invites versioning conflicts that need to be individually re-investigated. 

o    In the case of conflicts, users will not know which is accurate or may only view the inaccurate field. 

o    It is likely that processors removing a local access restriction will not uncheck each Restrictions Apply? box for children AOs. 

·         Restrictions Apply? gives no sense of what a restriction is. 

·         The checkbox is significantly more work to apply and maintain. 

·         Local Access Restrictions are far more visible and searchable in both the public and staff user interfaces. 

·         The software itself favors Local Access Restrictions.  

o    They are the mechanism used to flag boxes as restricted in Manage Top Containers. 

o    They are used in the currently staff-only Restricted badge in the PUI. 

·         Local Access Restrictions force processors to publicly indicate why something is restricted.  

o    You cannot add them without a Conditions Governing Access note, where the Center has developed standardized language for specific restrictions. 

o    The checkbox has no relevance to public users. 

Cons 

·         It can be difficult to locate parent Local Access Restrictions from the staff interface. 

·         It is difficult to query for children of restricted objects and cannot using the current database version

 

So Paul, while I like that text up high in the AO, it doesn't actually directly relate to the field that at least we are using to trigger restrictions. Unless, crazy thought, the application could automatically check that box for children of parents with machine actionable restrictions. I say this as a non-programmer.

 

Thanks,

Olivia

On Thu, Feb 22, 2024 at 8:32 AM Dan Michelson <dmich...@smith.edu> wrote:

Hi Olivia and Paul,

 

Many notes and subrecords, including Conditions Governing Access notes can be configured to be inheritable or not in the PUI by editing the yml file, that's what we've done here at Smith.  I highly recommend customizing this to fit your needs if you use the PUI, it's very easy.

 

All the best,

 

Dan

 

On Thu, Feb 22, 2024 at 9:26 AM Paul Sutherland <psuth...@amphilsoc.org> wrote:

Hi Olivia,

 

Thanks for raising this. We're about to do an overhaul of how some of our restrictions are displayed, and are also switching to the AS PUI, so this is timely for us.

 

I like the idea of a link.

 

On the PUI side, maybe this could be incorporated into the PUI inheritance. In this example, inherited fields from two different parents (a Collection and a Series) show. The text "From the Collection:" could become a link. Currently Conditions Governing Access notes do not display in this form in the PUI - they do not mention the source - but that could be brought in line with how these other notes show inheritance.

 

 

On the staff side, perhaps the link could be placed in this help text similar to the Publish help text. Both could have links from the word "ancestor" to be taken to the parent that causes this help text to appear. E.g.:

 

 

However, it's a bit tricky having these two places to flag restrictions ("Restrictions Apply" checkbox and "Conditions Governing Access/Use" notes). It always strikes me as a bit weird that these are so separate in the record. I figure the checkbox should not be automatically turned when a "Conditions Governing Access/Use" note exists, because DACS recommends having this note always present even to indicate an open resource/object. Maybe the help text here could clarify the specific source also of the restrictions (e.g. "This record has an ancestor with restrictions in the Conditions Governing Access note"). Or perhaps I'm overthinking this bit. Once at the record, staff can work out where to look.

 

Best,

Paul

On Wed, Feb 21, 2024 at 2:56 PM Olivia S Solis <livs...@utexas.edu> wrote:

Hello all,

 

I would like to file a JIRA request, but I am not entirely sure the best solution to an issue we have. The problem: If you are in a restricted archival object that has inherited a restriction from a parent via a Conditions Governing Access note, you have to do a lot of guesswork to locate the parent with the restriction. That restriction may be in a resource record or parent archival object, via a local access restriction or restriction dates.

 

This sometimes makes it difficult to remove/edit a restriction because the parent with the restriction may be difficult to locate. You also may not understand when you are editing/viewing at an AO with a restriction.

 

I am thinking that within a child AO with an inherited/indirect restriction, some kind of link similar to linked accessions or linked agents may work. However, those are subrecords that you manually add or in some cases are spawned. So it is a little different. This link would be dynamically updated or removed.

 

The other analog is the text that says if you click publish within an AO, that a parent is unpublished. But that text is not a link.

To view this discussion on the web visit https://groups.google.com/a/lyrasislists.org/d/msgid/Archivesspace_Users_Group/CAKu%2Bi%3D0wh%3Dg6nQ1Fak%3DAKKGHa-GSqv9HEEeuXzwU54u1HkbrTw%40mail.gmail.com.

[Paul Sutherland]

Hi all,

Yes, I'm also glad for the customization of displayed inheritance. I've flagged for us to use that as we move forwarded with our PUI. It's definitely favorable to be able to set restrictions at just the parent level.

We haven't been using Restrictions Apply historically, and I agree with the analysis of why this isn't as good as Local Access Restrictions. I hadn't realized how important that field itself was within Conditions Governing Access/Use notes - we're going to be using Aeon's request plugin too, so this article is also helpful extra reading on that.

Another idea is a label by the title that would link to the restricted parent:

Paul

[Olivia S Solis]

Oh, I like that badge up top, Paul! I don't know much about UX/design but if the label were clickable, taking you to the parent a restriction is inherited from, that seems highly desirable.

So, let me admit my ignorance, but Mary, I'm not familiar with ArcLight. Looks like I might be watching this webinar soon. It allows you add additional visual cues to restricted materials in the PUI? We are looking to make restrictions more obvious across the board, which is why I filed this issue yesterday.

This message is from an external sender. Learn more about why this matters.

[Olivia S Solis]

Hello all,

FYI, I filed this request. Paul, I hope you don't mind that I used your screenshot to demonstrate a potential solution. :) And Dan I think I misunderstood you before. We do have our PUI configured to display inherited conditions governing access notes. e.g this AO has inherited a restriction from the component immediately above it. The problem I wanted to address, though, is locating the parent in the staff user interface. The parent may be several levels up, which means you may have to click on a lot of parent's to find it.

I appreciate everyone's feedback!

-Olivia

[Michelle Paquette]

Olivia are you using machine-actionable restrictions, either restriction begin/end dates or the Local Access Restriction type? If you are, you may be able to find the relevant ancestor pretty easily by navigating to the top container of the archival object in question and looking at the linked records under "Active Restrictions" (only visible in View mode, not Edit mode). That's how I go about finding this kind of info. If you have a bunch of restricted stuff all in one container from different series/subseries with different restrictions it may prove more difficult to determine, but I think that's a pretty unlikely scenario.

Best,

Michelle

To view this discussion on the web visit https://groups.google.com/a/lyrasislists.org/d/msgid/Archivesspace_Users_Group/CAKu%2Bi%3D0vedgfF8aSb24rMECpxYeF%2BNHH%3DZUtmK552GhDxRcJ0w%40mail.gmail.com.

--

Michelle Paquette

(she/her)

Metadata & Technical Services Archivist

Special Collections

Smith College

413-585-7029

mpaq...@smith.edu

[Olivia S Solis]

We are using machine readable restrictions. That can sometimes be a solution, but not always. For instance, we will sometimes separate materials from several collections and put them in a restricted shared box, removing and reintegrating them if restrictions expire. Additionally we do have some very large collections with a large number of nested children with mixes of restrictions. For instance, we are the UT archives and there can be complicated restrictions involving FERPA/student records with staggered restriction dates all in the same box. That can also complicate the search for the ur-restriction. I do think the badge, in addition to helping you jump to the restriction, will help in letting you know you are in a restricted AO at all.

[Joshua D. Shaw]

We use the Restrictions Apply?​ checkbox to propagate restrictions down the tree, though in reality the indexer works from the bottom up.

 

The indexer customizations we use takes a look at an object and then traverses up the ancestor tree until it finds (or ultimately doesn't) something with that checkbox ticked. If it does, it records the level the restriction was found at. Then, in the staff UI, we display something like the attached.

The only drawback we've found to this approach is that it adds a significant amount of time to an indexer run since its an extra traversal of the tree for each object (because its a plugin). However, if this were added to core, then I believe the current traversal could just add some additional data as it collects the ancestor tree info.

Something similar could be done if notes or machine readable restrictions are used instead.

jds

---

From: archivesspac...@lyrasislists.org <archivesspac...@lyrasislists.org> on behalf of Olivia S Solis <livs...@utexas.edu>
Sent: Thursday, February 22, 2024 2:36 PM
To: Michelle Paquette <mpaq...@smith.edu>
Cc: Archivesspac...@lyrasislists.org <Archivesspac...@lyrasislists.org>

To view this discussion on the web visit https://groups.google.com/a/lyrasislists.org/d/msgid/Archivesspace_Users_Group/CAKu%2Bi%3D05w3D%3DWi4CBS0htHFeWoC5OuUeF4Ra2F1WFkKwSGvGug%40mail.gmail.com.