Print

Print


This has been very interesting.  I think another way to think
about this, which Dan has just alluded to, is how can archival descriptions
be migrated between systems without breaking the physical location
links?  We don't publish physical location information in our finding
aids either, but after the painstaking process of associating physical
locations to ca. 150,000 components and 3,000+ accession records, we  
will, of course, be interested in the interoperability of that  
information, especially if we can't benefit from a dedicated migration  
tool such as has been proposed for ArchivesSpace. EAD is the most  
common exchange format in this case, so it makes sense to explore how  
an application can encode physical location information in EAD even if  
it is never shown to the end user.  Dan is right about his  
characterization about best practices for this sort of thing, but I'm  
sure we have cases similar to his second example.

Glad to hear all these responses!  Always interesting to hear how  
people manage their physical holdings and relationships to the  
descriptive information.

Cheers,

Creighton

On 4/17/2013 9:01 PM, Dan Gillean wrote:

> 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:
> https://www.ica-atom.org/doc/What_is_ICA-AtoM%3F. 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.
> www.artefactual.com