Hi Roula,

My name is Jessica, and I am one of the Product Managers for ICA-AtoM. The step-by-step documentation for downloading and installing the software can be found here: It also includes information about the minimum requirements for installing the system.

If you have additional questions about ICA-AtoM installation, please post a message to our Community User Forum:!forum/ica-atom-users. Additionally, any further questions regarding hosting services etc. can be found on the Artefactual Systems website:, or contact us: mailto:[log in to unmask].


Jessica Bushey, MAS
ICA-AtoM Product Manager
Systems Analyst
[log in to unmask]

Artefactual Systems Inc.

On 2013-04-19, at 2:02 AM, Roula Harb wrote:

Dear Dan,

I am a librarian working in an archival project at Notre Dame University, Louaize Lebanon(country Lebanon),
I am in Paris to attend an STIA 2013 international technical archival training. we had a practical life demo on how we use ICA_ATOM, i am really interresed to install this software in our library and start the archival description .
could you help on sending me outline on how to start this application, we work closly with the division of computer center and an IT personnel in the library,

thank you


Roula Awad Harb
Head, Acquisitions Department

-------- Message d'origine--------
De: Encoded Archival Description List de la part de Dan Gillean
Date: mer. 4/17/2013 9:09
: [log in to unmask]
Objet : Establishing a relationship between containers and physical location

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 ( 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, (, 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

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:

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

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


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

     <container type="box">

                 <title>box 999</title>


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

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

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


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




Thank you in advance,

Dan Gillean

AtoM Product Manager / Systems Analyst

Artefactual Systems, Inc.