Print

Print


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
>