I don't know if this fits within "best practice" or not, but I can explain a little bit about what we do. We have a box inventory system that manages our records center. This system offers space management and good control of what is located where. When boxes become part of our permanent archives, the physical boxes are moved into a storage space whose locations are managed by a robotic automated storage retrieval system (ASRS). Although the containers retain the same barcode as from the box inventory system, the box inventory system no longer knows exactly what shelf those boxes are located on--just that they are located in our permanent records room. Only the ASRS database knows the actual shelf location.

The box inventory system is fully integrated with our archives management system, which is the software we use to manage our entire workflow, including EAD export. In it, we provide space to describe each container. These "processed containers" are intellectual descriptions of records which may have complex relationships to actual physical containers. We don't start with a physical container and describe its content, we describe records and then provide pointers to all the containers in which these records are housed. As such, the archives management system offers a feature that allows the user to scan the barcodes of containers into a new table in the order that they want the container to appear in the finding aid. Then when container descriptions are typed or imported into the archives management system from spreadsheets, the container numbers associated with those descriptions match the key values from the new table where barcodes were scanned. So this new table is a bridge between the physical box inventory system and the EAD container list. With the barcode links in place, we can order boxes for patrons from the archives management system, which sends the request to the staff who man the automated storage retrieval system. This request is currently sent via email with a list of barcodes and series titles and agency names associated with the records. We technically could make our archives management system talk directly to the ASRS and make the robots move to retrieve the shelf with each order, but we've opted not to do that (causes headaches with the robots). There is also now a new box inventory feature contained within our archives management system that, if used, would likely make linking physical boxes with processed containers much easier, but we are used to our old box inventory system and have no reason to change at this time.

To make a long story short, we do not publish exact shelf locations in EAD at all. I consider that a security risk. Instead, we indicate the city and/or storage room where the containers reside in <physloc>, in order to inform the patron how much advanced notice they might need to give us to provide the record. We consider EAD just one form of output from our database that helps patrons find the records they need. It is not a place where we try to record all the metadata we have access to about any given record.

If you are curious about the technology we are using, our box inventory system is Versatile, our ASRS is provided by HK Systems, and our archives management system is AXAEM.

Elizabeth Perkes
Electronic Records Archivist
Utah State Archives
346 South Rio Grande
Salt Lake City, UT 84101
801-531-3852
[log in to unmask]




On Wed, Apr 17, 2013 at 12:09 PM, Dan Gillean <[log in to unmask]> wrote:

Greetings colleagues,


My name is Dan Gillean; I am one of the Product Managers for ICA-AtoM, an open source, web-based archival description software application (www.ica-atom.org). I am wondering if anyone here might have some thoughts on managing relationships between physical location(s) and containers.

 

 AtoM’s physical location manager was added before my time and, pending development support from our community of users, something we hope to improve in future. For now, I am working to revise our EAD import/export to conform to best practice as much as possible, while ensuring that user data is not lost when roundtripped. For context to my question, you can see our existing interface for linking physical location information by going to our demo site, logging in with the credentials provided on the home page, (http://demo.ica-atom.org), navigating to one of the demo archival descriptions, and clicking on “Link physical location.” We provide 3 fields:  type (which contains values such as box, folder, etc. – mapped to <container type=XXX>), name (mapped to <title> within <container>), and location (mapped to <phsyloc>). This option to link physical locations is available on all levels of description, and can be repeated. Consequently, while the use case is low, a user might reasonably include multiple location links in a single <did>, with different physical locations – if, for example, someone chose to link physical location information at the fonds or collection level, indicating multiple boxes across different storage locations. Conceivably, it might also be possible within a single file-level description, if, say a file spanned several folders, which fit into 2 boxes, which happened to be at the end of a shelf, meaning the second file would be in a new box on a different shelf.

 

My question is: given this possibility, is there some acceptable and/or best practice method for providing a relationship in EAD between a <container> and a <physloc>?

 

Some possibilities that have occurred:

 

1) Assigning an ID to the <physloc>, and the same ID to the related <container> (s), so we can relate them on import. We might also use @PARENT in the <container>, but my understanding is that this should be used for a parent container, such as a folder in a box, and not to relate a container to a location.

 

2) One of our developers has suggested using a <ref> element, which is available within both <container> and <phsyloc>, to link the two – but again, I have hesitations about this as a practice, especially if we want to keep our EAD export records interoperable with as many other systems as possible.

 

3) We have noted that @PARENT is available in both <physloc> and <container>, meaning it could be possible to add an ID to <physloc> and a corresponding @PARENT to the <container>. However, my understanding is that @PARENT is generally used to relate two of the same elements: for example, a <container type=”folder”> inside a <container type=”box”>. We wish to ensure that we are conforming to best practice as much as possible, and that we’re doing everything we can to support wide interoperability, and this solution seems like it might be a bit of a hack.

 

For those interested, you can see the context of our discussion on this issue on its related ticket, here: https://projects.artefactual.com/issues/3850

 

Does anyone have suggestions, advice, or examples on how we might best maintain this relationship? Thoughts on the possible strategies listed above?

 

Here’s an example of the problem we are trying to solve:

 

<pre>

 

<physloc>Shelf 3R, Aisle 1</physloc>

      <container type="box">

                  <title>box 999</title>

        </container>

<physloc>Shelf 3R, Aisle 1</physloc>

        <container type="box" label="hollinger">

                  <title>123-4</title>  <!-- container with same physloc as  box 999 -->

          </container>

          <container type="box" label="cardboard"> <!--a container without a physical location specified -->

                  <title>35</title>

          </container>

          

</pre>

 

Thank you in advance,

 

Dan Gillean

 

AtoM Product Manager / Systems Analyst

Artefactual Systems, Inc.

www.artefactual.com