[Archivesspace_Users_Group] Managing Unique Top Containers
Dan Michelson
dmichelson at smith.edu
Wed Aug 2 14:53:16 EDT 2023
We just bit the bullet and renumbered ~6,000 boxes last Fall. It was
absolutely worth it, since non-unique box numbers in collections constantly
require weird workarounds. No more researchers having to specify which of
the 120 different box 1s in a collection is what they're actually looking
for.
If anyone is interested in the workflows and associated python script we
came up with to carry this out without significantly disrupting collection
use, feel free to contact me.
All the best,
Dan
On Wed, Aug 2, 2023 at 11:10 AM Hand, Sarit <shand at ap.org> wrote:
> Hi,
>
>
>
> We have similar scenarios.
>
> Because you can create multiple top containers with the same indicator
> without getting an error, items in collections were randomly labeled with
> different top containers but with the same indicator. That’s been an
> ongoing clean up job.
>
>
>
> To alleviate this, I did not create complex top container names because
> our physical boxes already had labels with their box indicators which were
> simple digits, 1, 2,3 or even 01, 02 03, etc. (also not consistent);
> instead, I used the barcode field and put the collection, series, and box
> info there. We were not using barcodes at the time. It helped immensely
> since that meant I did not have to relabel the physical boxes with new box
> numbers etc. but allowed be to distinguish between Box 1 for series 1 and
> Box 1 for series 2 and so on.
>
>
>
> However, we just started using barcodes, which in effect will still help
> to distinguish the separate top containers, just won’t have the collection
> data in there. The downside of creating Box indicators and/or barcodes
> using collection data is if you must store content from multiple resources
> in the same top container then the data will not make sense. The downside
> of using generic barcode numbers is that it is not informative, its just a
> random set of characters.
>
>
>
> Bottom line, I use the barcode field to distinguish top containers with
> the same indicator in a resource whether it has collection info or not.
>
>
>
> Cheers,
>
>
>
> Sarit Hand 200
> Liberty St.
>
> Digital Archivist New York,
> NY 10281
>
> Corporate Archives T 212.621.7035
>
>
>
>
> shand at ap.org
>
> www.ap.org
>
> *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org <
> archivesspace_users_group-bounces at lyralists.lyrasis.org> *On Behalf Of *Bowers,
> Kate A.
> *Sent:* Tuesday, August 1, 2023 11:45 AM
> *To:* Archivesspace Users Group <
> archivesspace_users_group at lyralists.lyrasis.org>
> *Subject:* Re: [Archivesspace_Users_Group] Managing Unique Top Containers
>
>
>
> [EXTERNAL]
>
> We have an enormous number of legacy collections where the container
> numbering has similar issues. Fortunately (or because of this) we are not
> trying to use AS as our system of record for locations or container
> management.
>
>
>
> The best solution we found with ArchivesSpace is to repeat the entire text
> of the container identifier in the “indicator” field of the top container.
> For example:
>
> - HUGFP 26.10 Box 1
>
>
> - HUGFP 26 being the collection identifier, .10 being the series
> identifier, and Box 1 being the container number
>
>
> - HUGFP 111.75 p Box 1
>
>
> - (HUGFP 111 being the collection number, .75 being the series
> identifier, p being the container prefix, and Box 1 being the container
> number
>
>
>
> This is, at least, accurate. It does make the public display weird in some
> places though.
>
>
>
> This is a legacy practice—we no longer assign series or sous-fonds
> numbers to portions of fonds or portions of collections that will be
> described in a single finding aid. For many institutional records, the
> description is at the sous-fonds or series level. We will continue to have
> the problem with legacy collections, however.
>
>
>
> Kate
>
>
>
> *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org <
> archivesspace_users_group-bounces at lyralists.lyrasis.org> *On Behalf Of *Herbert
> Dittersdorf
> *Sent:* Tuesday, August 1, 2023 11:23 AM
> *To:* archivesspace_users_group at lyralists.lyrasis.org
> *Subject:* [Archivesspace_Users_Group] Managing Unique Top Containers
>
>
>
> Hello ArchiveSpace Community,
>
>
>
> I was hoping to crowdsource a little wisdom about Top Containers and how
> you all manage them.
>
>
>
> I am retooling the finding aid for the University of Maine's William S.
> Cohen Papers collection--a very large set of boxes (our largest). The
> collection contains multiple record groups, series, sub series, and
> sub-subseries. Boxes and files have been associated with Top Containers
> successfully; however, the Top Container designations tend to be generic
> (e.g. "Box 1," "Box 2," "Box 3"...). This fact creates a problem: each "Box
> 1," "Box 2," "Box 3"... Top Container is linked with records from disparate
> series and subseries.
>
>
>
> For example, the following two folder titles are both linked under the
> same "Box 1" Top Container:
>
>
>
> One file comes from subseries, *2.1.5 Membership Files. * The other file
> comes from the subseries, *3.4.4 Mailings.*
>
>
>
> Obviously the details do not matter here. I am simply wondering how others
> deal with similar problems. Generally: *Is there a way to create unique
> top container instances with identical titles? *Or do you all
> typically embed additional information in the "Top Container" title?
>
>
>
> In the case of the example: Can I create two unique "Box 1" instances (one
> for the 2.1.5 subseries and the other for the 3.4.4 subseries) by editing
> the metadata for that Top Container in some way? Or is creating a longer
> "Top Container" title (something like, "2.1.5 Box 1") the only way to solve
> this problem?
>
>
>
> I am looking for an elegant way of solving this issue without creating
> long Top Container titles but could not find a way to do so using the Help
> Center. Even knowing, for sure, that I have to create longer titles would
> be very helpful.
>
>
>
> Thank you so much and I apologize for clogging all of your inboxes with my
> question!
>
>
>
> Sincerely,
>
> Herbie Dittersdorf
>
> --
>
> Herbert Matthew Dittersdorf, M.S.I.
>
> Archivist, William S. Cohen Papers
>
> Special Collections Department
>
> 5729 Fogler Library
>
> Orono, ME 04469-5729
>
> 207.581.1844
>
>
>
> The information contained in this communication is intended for the use of
> the designated recipients named above. If the reader of this communication
> is not the intended recipient, you are hereby notified that you have
> received this communication in error, and that any review, dissemination,
> distribution or copying of this communication is strictly prohibited. If
> you have received this communication in error, please notify The Associated
> Press immediately by telephone at +1-212-621-1500 and delete this email.
> Thank you.
> _______________________________________________
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group at lyralists.lyrasis.org
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>
--
Dan Michelson
Collections Archivist
Smith College Special Collections
For current library access and services details, see Library Services
During COVID-19
<https://libraries.smith.edu/library-services-during-covid-19>.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20230802/c99fe1a7/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 5729 bytes
Desc: not available
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20230802/c99fe1a7/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.jpg
Type: image/jpeg
Size: 1715 bytes
Desc: not available
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20230802/c99fe1a7/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.png
Type: image/png
Size: 50746 bytes
Desc: not available
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20230802/c99fe1a7/attachment-0001.png>
More information about the Archivesspace_Users_Group
mailing list