linking physical storage

140 views
Skip to first unread message

m.gor...@gmail.com

unread,
Dec 14, 2018, 6:38:54 PM12/14/18
to AtoM Users
At the risk of wearing out my welcome, I present a question about linking physical storage to files.  I assigned all of the files to Box 1 in the storage1 screen shot, which I created as a new container at that time.  Then I created a test collection and assigned the two test files to a second newly created Box 1 (storage2 pic).  Then, in the test collection, when I try to link a given file to the existing box 1 created for the test collection, 2 box 1's appear in the existing container list (storage3 pic).

I guess I assumed that the box created for the Vita collection would not be a selectable option for the "test" collection.  If, when linking physical storage to files, how is the archivist supposed to know which is the correct "box 1" in the drop down list?  Ten collections would mean ten "box 1s" appearing on the list.

We don't ID our containers specific enough as shown in the AtoM manual example of C-005, C-006.  It is simply "box 1."

Thanks,
Matt G
SIU Carbondale
storage1.png
storage2.png
storage3.png

Corinne Rogers

unread,
Dec 17, 2018, 3:11:00 PM12/17/18
to AtoM Users
Hi Matt,

Don't worry about wearing out your welcome - it's not possible! :)

Currently AtoM's physical storage module is very basic. The only way to avoid seeing multiple, indistinguishable choices for "Box 1" when you link physical storage is to have more granular information about your storage locations in their name, regardless of how you actually label the physical containers. When you link physical storage the dropdown list will autocomplete, showing every option that begins with what you type. So if you type "B", autocomplete will offer every storage location named "B*" - in your case "Box 1". In your examples it doesn't appear that there is any information in the physical storage name to distinguish between your two "Box 1"s, and there is no location description. If you can add just a bit more information to the name that will eliminate this problem: example, SH1-Box1 and SH2-Box1 indicating box 1 on shelf 1 and box 1 on shelf 2.

I have created an example: 
In the screenshot below you can see three storage locations, two of which are "Box 1" but with more qualifiers in the name, and a location description. These three locations have been created to use with my test description 'Christ Church Cathedral Fonds'.

storage name.png


In the next screenshot I am trying to link the file "PC Minutes 2002" to a storage location, and you see all the available physical storage locations that begin with the letter C in my demo AtoM site. 

storage linking.png


In the final screenshot I have linked a file to one of these physical storage locations. You can see the name and the location description at the bottom right.

storage info.png


Without enough information in the name you won't be able to distinguish between different instances of "Box 1".

You can find more information about physical storage in these two threads as well:

I hope this helps! Let us know if you have further questions about this.

best regards,

Corinne 
Systems Analyst
Artefactual Systems

m.gor...@gmail.com

unread,
Jan 14, 2019, 12:21:13 PM1/14/19
to AtoM Users
Corinne,

Thank you.  Creating an alphanumeric code, like CCC in your examp.e to distinguish boxes is one workaround.  But it can be problematic in the long run, especially in a university setting where units change names every few years and the code wouldn't necessarily reflect the new name.

Creating a code based on shelf location is also insufficient because collections can move around for various reasons.

It may have been Dan who said in the past, for people coming into AtoM from Archon, that they've been able to make box a 'level' of description.  That might be the best way for us to go.  We would not treat the box as a descriptive entity (title, date, scope), but it would really only serve as a structural element that helps archivists and researchers know which boxes to pull when files are requested.

Do you have any examples of what Dan is talking about?  And how would the PDF look using the 'generate finding aid' link?

Thanks, matt




Dan Gillean

unread,
Jan 14, 2019, 12:48:30 PM1/14/19
to ICA-AtoM Users
Hi Matt, 

Trinity is a former Archon user who has implemented the "Box as level" approach. I found an example in their site that has a PDF finding aid attached: 
Here are other descriptions with a level of "Box" in their system: 
It looks like there are improvements we need to make to the XSLT that generates the finding aids, because right now it is displaying as "otherlevel"! 

Consequently, I have filed a bug report here: 

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056
@accesstomemory


--
You received this message because you are subscribed to the Google Groups "AtoM Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ica-atom-user...@googlegroups.com.
To post to this group, send email to ica-ato...@googlegroups.com.
Visit this group at https://groups.google.com/group/ica-atom-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/3b5212a7-64e1-4a1a-aeb0-86160dedb746%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Nathanael

unread,
Jan 16, 2019, 10:08:17 AM1/16/19
to ica-ato...@googlegroups.com
I usually put the name of the collection into the box name, e.g. 'Michael Harverson Box 1' (https://catalogue.millsarchive.org/michael-harverson-funeral-order-of-service) or 'Derek Ogden UK Files Box 1'  (https://catalogue.millsarchive.org/chesterton-windmill-warwickshire-2)

m.gor...@gmail.com

unread,
Jan 16, 2019, 2:49:13 PM1/16/19
to AtoM Users

Dan,

Thanks for the Trinity example.  I like how it looks on the tree view on the left side of the screen.  Yes, box in this case is treated as a level of description.  But ideally, as it is done in Archon, the box 'level' would only be a structural entity rather than an intellectual level that can be described.  So the Trinity example would have Box in the tree view on the left, but it would function only as something to click on that then shows the files within the box.  You wouldn't have the screen that presents box as an archival description with metadata, etc.  Can AtoM do that?
yes_and_no.png

Dan Gillean

unread,
Jan 16, 2019, 5:15:46 PM1/16/19
to ICA-AtoM Users
Hi Matt, 

Unfortunately AtoM can't do that at present. This comes back to the distinctions I mentioned between the physical and intellectual arrangement differences between Archon and AtoM. I think it's also like that Archon and AT's functionality has had a hand in shaping many U.S. arrangement practices, much like AtoM has helped shape some Canadian practices, by being a sort of de facto application for a long period of time. 

Ideally in AtoM, you would use the physical storage module for the box level information - it shouldn't matter to researchers how your institution has chosen to house the materials, so long as they still have  a way of requesting what they want to see, and your staff has a way of knowing what containers to retrieve. Unfortunately, this is complicated by the fact that no one has sponsored useful development of AtoM's physical storage module in a very long time, and it still doesn't have all the functionality required (such as hierarchical organization, and more) to make this a very practical alternative without some careful container naming and usage conventions set up in advance. 

In the meantime, if you are trying to recreate Archon in AtoM, I suspect you might keep running into these kind of decision points where you need to make a compromise and/or workaround in one direction or the other. In this case, I think you can try to find a way to make AtoM's physical storage module work for you, and perform transformations on your EAD exports during a migration to move this data to the storage module, or you will have to continue treating the boxes as intellectual entities to have them display in your treeview with some metadata (...or you can contact me off list to discuss sponsoring feature development!). I hope you find a solution that will work for your needs! 

I was curious to see if this Archon behavior has been carried forward into ArchivesSpace. However, as far as I can tell, ArchivesSpace also no longer displays container information in its treeview, either in the public or the admin interfaces. 

Regards, 

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056
@accesstomemory

On Wed, Jan 16, 2019 at 2:49 PM <m.gor...@gmail.com> wrote:

Dan,

Thanks for the Trinity example.  I like how it looks on the tree view on the left side of the screen.  Yes, box in this case is treated as a level of description.  But ideally, as it is done in Archon, the box 'level' would only be a structural entity rather than an intellectual level that can be described.  So the Trinity example would have Box in the tree view on the left, but it would function only as something to click on that then shows the files within the box.  You wouldn't have the screen that presents box as an archival description with metadata, etc.  Can AtoM do that?

--
You received this message because you are subscribed to the Google Groups "AtoM Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ica-atom-user...@googlegroups.com.
To post to this group, send email to ica-ato...@googlegroups.com.
Visit this group at https://groups.google.com/group/ica-atom-users.
Reply all
Reply to author
Forward
0 new messages