[Archivesspace_Users_Group] Use of the "Relator Type" subfield in the "Related Accessions" field

Jordon Steele jsteele at jhu.edu
Fri Feb 16 09:38:36 EST 2018


Hi Mike,

Thanks for the explanation. Very useful.

Best,

Jordon

Jordon Steele
Hodson Curator of the University Archives
Special Collections
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 Rush, Michael
Sent: Friday, February 16, 2018 9:07 AM
To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org>
Subject: Re: [Archivesspace_Users_Group] Use of the "Relator Type" subfield in the "Related Accessions" field

Hi Jordan,

The Related Accession functionality was something developed here at Yale (working with Hudson Molonglo).

When you select the "Part of" relationship type, I believe there is by default only one relator type, "Part" relationship. Admittedly this is a bit duplicative, and we have not added any additional relator types for part relationships.

When you select the "Sibling" relationship, by default the only option is "Bound With." We use this in the case of early modern manuscripts which we accession at the title level, but which can often be bound together with other manuscripts into a single volume. We have also added an "in lot" relationship, which for us denotes two accession records that represent a single line item on an invoice and share the same purchase details, but for which we have decided to treat a distinct intellectual objects. That's the use case - subclassing sibling relationships - that lead us to add the relator types.

Admittedly this is all a bit of a tangle and I might approach it differently now.  For your purposes, I would leave the relator type for part relationships as it is, and if you use sibling relationships I'd create delete the bound with relator, and replace it with a simple "sibling" relator. That would ensure that the data is accurate and complete, in case down the road you want to add different relator types. And you could suppress the field from the interface knowing that the default values are being added.

Hope this helps,

Mike

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] On Behalf Of Jordon Steele
Sent: Thursday, February 15, 2018 3:37 PM
To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>>
Subject: [Archivesspace_Users_Group] Use of the "Relator Type" subfield in the "Related Accessions" field

Hi folks,

We're discussing the utility of the "Relator Type" subfield in the "Related Accessions" field. By default, ASpace requires this subfield, but we are considering suppressing it because we can't think of a reason why we would want to use it. The default value, "bound with," suggests two accessions physically linked (like two accessions in one box), but we manage relationships like these via container management. To us, noting if a related accession is a sibling or part of relationship is enough.

If you're a user of this subfield or consciously not one, comments are welcome!

Best,

Jordon

Jordon Steele
Hodson Curator of the University Archives
Special Collections
The Sheridan Libraries
Johns Hopkins University
3400 N Charles St
Baltimore, MD 21218
410-516-5493
jsteele at jhu.edu<mailto:jsteele at jhu.edu>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180216/938e030e/attachment.html>


More information about the Archivesspace_Users_Group mailing list