[Archivesspace_Users_Group] Managing Unique Top Containers
Olivia S Solis
livsolis at utexas.edu
Wed Aug 2 15:38:11 EDT 2023
Hi there,
I'm not sure how feasible this is for your institution, but barcoding has
made all the difference in the world for us. This is a screenshot of a top
container record with an indicator that is not unique:
[image: Screenshot 2023-08-02 at 2.19.42 PM.png]
In our workflows, we add new inventories via the spreadsheet uploader. If
in the template you include barcodes, the importer will use the barcode to
determine if the box is unique or not. If you include the barcode and the
box is already in the system (e.g. it's a shared box for oversize or
contains restricted materials), it will link to. that existing box. If the
barcode is to be created with that upload, it will create a new e.g. "Box
1" for every box 1 with a new barcode. The nice thing about this is it will
stop you from duplicating a box. ASpace won't let you create a box that
already has the same barcode in the system.
Not all our containers are barcoded. For those that are not, we go so far
as to invent fake barcodes after they are created as a hack. Our system is
to give it a [buidling prefix]_[aspace top container ID]. This allows us to
link to that box in other inventories. That has to get added after a
container is created. In theory, though, you could assign even invented
barcodes beforehand.
I'm not sure if leveraging the barcode would work for your particular
workflows or not.
Best,
Olivia
On Wed, Aug 2, 2023 at 1:53 PM Dan Michelson <dmichelson at smith.edu> wrote:
> 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>.
> _______________________________________________
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group at lyralists.lyrasis.org
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
> >> This message is from an external sender. Learn more about why this <<
> >> matters at https://links.utexas.edu/rtyclf. <<
>
--
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20230802/ee535ce0/attachment-0001.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/ee535ce0/attachment-0003.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/ee535ce0/attachment-0001.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/ee535ce0/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot 2023-08-02 at 2.19.42 PM.png
Type: image/png
Size: 71017 bytes
Desc: not available
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20230802/ee535ce0/attachment-0005.png>
More information about the Archivesspace_Users_Group
mailing list