Hello all,

Just a quick follow to say thank you for your helpful suggestions.

For those unfamiliar and curious, AtoM is a web based application that
stores user data in a MySQL database, using PHP to serve the end user
templates in HTML - you can learn more about the application and its
architecture here:
Because everything is managed via a simple GUI and storage can be linked to
an archival description, there's no need to update the finding aids when
physical location changes - merely update the physical location and the
information is already attached to the archival description.

As for security, we have considered this in the way that end users can
access our EAD, and will be allowing archivists to hide information they do
not want included on export (this option is already available in our GUI
via the "Visible Elements" settings, which can hide certain fields for
non-authenticated users). Regardless, for many of our users, EAD is their
preferred, standards-compliant way to migrate information between systems,
and because it is possible to encode these fields within EAD, we've chosen
to do what we can in our application to allow users to include this
information in their exports when they want it.

Best practice implies that users are applying physical location and
container links at the appropriate level (file or item, for example), which
would avoid the problem edge cases that initiated this question in the
first place. However, the real world, and what people want, is often
different from ideal use, and we are trying to accommodate an international
user base with very diverse interests, intentions, and use cases, while
still conforming to best practice as much as we can.

Michael, thank you for the reminder about the <title> element!  I have come
to working on this issue based on what we had in place prior to my
revisions, and am not sure when the <title> element was added - I've noted
that in EAD 2002 it is allowed within <container>, but you are correct it
does not conform to the element's description, and does not seem necessary
in any case. I've been so focused on working out the relationships that I
had not yet had a chance to review this. Good to know as well that this
will be one of the changes coming down the pipe with the current revisions.
I will be recommending to our developers that we remove this element from
our physical location module. Personally, I do think that keeping @parent
included in <physloc> is useful, for the exact use case that you suggested
(several shelves within a range, etc.), so I am also glad that my question
has inadvertently provided you with a use case for its maintenance.

Once again, I appreciate the time everyone has taken to respond to this
issue, and the speed at which it has been addressed. Likely we will look at
referencing physloc/@id in container/@parent to solve this problem  - I
can't think of a use case where a single container would need to reference
more than one physical location - our problem has been moreso with
associating one or more containers with a specific physical location, which
this should solve.

Many thanks,

Dan Gillean

AtoM Product Manager/Systems Analyst,
Artefactual Systems, Inc.